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Sir: 

We, John S. Brown, Diana Sinor, and Dilip J. Patel, hereby declare as 
follows: 

1 . We are the inventors of the subject matter claimed in the above- 
identified patent application. 

2. We have been informed that U.S. Patent Publication No. 
2003/0195780 to Arora et al. (hereinafter Arora) has been cited as prior art by the 
United States Patent and Trademark Office with respect to the above-identified 
patent application. We also have been informed that the earliest possible 
effective prior art date of Arora is no earlier than December 13, 2001. 
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3. This declaration is being submitted to establish conception and 
reduction to practice of the invention claimed in claims 1-16 and 18-21 of the 
above-identified application in the United States prior to December 13, 2001. 

4. Prior to December 1 3, 2001 , we had conceived of and developed 
(i.e., reduced to practice) a working software program that met all of the 
limitations of claims 1-16 and 18-21 of our patent application, as more particularly 
detailed below. 

5. Exhibit A attached hereto is a copy of the Business Requirements 
for the project that resulted in the present invention. The date on the document 
has been redacted. However, it is prior to December 13, 2001 and accurately 
reflects the date of the document. 

6. Exhibit B attached hereto is the Program Functional Specification 
for the present invention prepared by one or more of the named inventors 
describing the relevant software as it existed on the date of the document 
preparation. The document includes several dates that have been redacted, 
including a creation date at the top of page 1 and then the date on which it was 
reviewed and approved by each of the eight people listed at the bottom of the 
last page. The dates on the document have been redacted. However, all dates 
are prior to December 13, 2001 and accurately reflect the true dates of the 
corresponding creation or review. 

7. Exhibit C attached hereto is the Program Functional Specification 
for the error correction facility portion for software that had to interface with the 
software of the present invention. Exhibit C. The dates on the document have 
been redacted. However, all dates on the document, including the date listed 
under "Last Changed By" are prior to December 1 3, 2001 . Under the heading 
"Capitalizations, including Posting to WIP", you will find a list of tax location fields. 
These fields were added to the facility as a result of the new errors produced by 
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the tax location program that had to be corrected. Similar fields can be found in 
the "Transfers Screen" section which follows the capitalization section. 

8. A program in accordance with the Program Functional Specification 
(Exhibit A) was coded immediately after the document was completed and the 
software passed testing shortly thereafter. All of these events occurred prior to 
December 13, 2001. 

9. Exhibit D attached hereto is a memorandum prepared by co- 
inventors Diana Sinor (maiden name Diana Hill) and John S. (Sim) Brown 
concerning the development of the invention disclosed and claimed in the above- 
identified patent application. The dates appearing on the original of this 
document have been redacted from the copy attached hereto. However, every 
redacted date is prior to December 13, 2001 . Software in accordance with the 
invention claimed in this application had been developed and deployed for its 
intended purpose prior to the preparation of this document. 

10. The present application discloses a method and apparatus for 
determining the tax location of a capitalized fixed asset. In particular, in 
accordance with one embodiment, when a transaction concerning a particular 
asset is recorded, the transaction record is provided to the tax location finder 
module. The tax location finder module runs through a hierarchical sequence of 
queries of the information assigned to the assert. In each query, the tax location 
finder module checks to determine if the data assigned to the asset meets a set 
of criteria that helps indicate a particular routine (or audits) that will probably be 
able to derive the tax location of the asset. Such criteria typically might comprise 
conditions that indicate the type of asset (e.g., manufacturing equipment/real 
estate/furniture), the name of the assets use (e.g., internal/customer- 
site/loaner/vendor-site), and/or the building, employee, or cost center to which 
the asset is assigned. If the data associated with the asset meets the set of 
criteria for a particular audit, then that audit routine will be called. If the asset 
does not meet the query criteria for an audit, then the software will continue on to 
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the next sequential query until it encounters a query whose criteria it meets. 
Each audit is customized to the asset or transaction qualities that caused it to 
. meet the criteria for calling that audit. The called audit attempts to derive the 
location of the asset. If the audit routine discover sufficient data to derive a tax 
jurisdiction code, then the derived tax jurisdiction code is passed back. If not, the 
transaction record is sent to an error correction facility where it may be manually 
researched and corrected. One or more of the audit routines may be designed to 
return the record transaction back to the hierarchy of queries if the audit fails for 
certain reasons. 

1 1 . We conceived and reduced to practice the invention claimed in 
claims 1-21 of the above-identified patent application prior to December 13, 
2001. All of Exhibits A, B, C, and D accurately reflect or discuss software that 
had been actually developed and written prior to December 13, 2001. 

12. The attached claim table maps the claims element-by-element to 
the evidence submitted herewith. 



CLAIM TABLE 



Claim Recitation 


Exemplary Corresponding 
Disclosures 
in Exhibits 


1 . A method of tracking the 
location of capitalized fixed assets for 
tax and/or insurance reporting 
purposes, said method comprising 
the steps of: 


Exhibit D, page 2, lines 10-16. 


(1) detecting when a 
capitalized fixed asset is involved in a 
transaction; 


Exhibit D, page 2, lines 19-20. 


(2) responsive to such a 
detection in step (1), running data for 
said asset through a plurality of 
queries, each query designed to 
determine if said asset meets a set of 
criteria indicative of a category of how 
a location of said asset for tax and/or 


Exhibit D, page 2, lines 19-22. 
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insurance reporting purposes may be 
determined; 




(3) if, in step (2), said asset 
meets said set of criteria 
corresponding to one of said queries, 
running data corresponding to said 
asset through an audit customized to 
said corresponding category to 
determine a location of said asset for 
tax and/or insurance reporting 
purposes; 


Exhibit D, page 2, lines 23-25. 


(4) if, in step (3), a location is 
determined, assigning said 
determined location to said asset for 
tax and/or insurance reporting 
purposes; 


Exhibit D, page 2, lines 23-25. 


(5) if, in step (3), a location for 
tax and/or insurance reporting 
purposes is not determined issuing 
an error notification; and 


We were unable to readily find actual 
error codes and descriptions directly 
demonstrating this claim feature. 
However, it was incorporated in the 
inventive software as reduced to practice 
and actually implemented prior to 
December 31 , 2001 . Exhibit C is indirect 
evidence of this; particularly the sections 
entitled "Capitalization including Postings 
to WIP" and "Transfer Screen". As 
described above in paragraph 7, these 
sections of Exhibit C reflect changes that 
were made to software that interfaced 
with the inventive software in order to be 
compatible with error codes generated 
by the present invention in accordance 
with this feature of the invention. 


(6) if, in step (2), if said data for 
said asset does not meet said criteria 
of any of queries, issuing an error 
notification. 


Exhibit D, page 2, lines 23-25. 






\ ne mexnoa 01 ciaim i 
wherein, in step (2), each of said sets 
of criteria comprises at least one 
criterion to which said data for said 
asset must match. 


bxniDit u, page 2., lines zu-zi. 






3. The method of claim 2 


Exhibit D, page 2, lines 21-22. 
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wherein, in step (2), said data for said 
asset is run through said plurality of 
queries hierarchically, wherein, when 
said asset meets said set of criteria of 
a particular query, said asset data is 
not run through any queries ordered 
lower in said hierarchy. 








4. The method of claim 3 wherein 
said transaction comprises a transfer 
or capitalization. 


Exhibit D, page 2, lines 14-16. 






5. The method of claim 3 wherein 
said error notification issued in step 
(5) indicates that the asset met said 
set of criteria corresponding to one of 
said categories, but was not assigned 
a location for tax and/or insurance 
reporting purposes. 


See claim 1, step (5) discussion in this 
table. 






6. The method of claim 5 wherein 
said error notification issued in step 
(5) further indicates which of said at 
least one criterion caused said error. 


See claim 1 , step (5) discussion in this 
table. 






7. The method of claim 5 wherein 
said error notification issued in step 
(6) indicates that said asset data did 
not meet said criteria corresponding 
to any category. 


Exhibit D, page 2, lines 23-25. 






8. A computer readable product 

_ i i * i . iii 
embodied on computer readable 

media readable by a computing 

device for tracking the location of 

capitalized fixed assets for tax and/or 

insurance reporting purposes, said 

product comprising computer 

execuiaoie instructions tor. 


Exhibit D, page 2, lines 10-16. 


(1) interfacing with external 
software to become aware of when a 
capitalized fixed asset is involved in a 
transaction; 


Exhibit D, page 2, lines 19-20. 


(2) responsive to such a 
detection in step (1), accessing data 


Exhibit D, page 2, lines 19-22. 
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for said asset and running said data 
through a plurality of queries, each 
query designed to determine if said 
asset meets a set of criteria indicative 
of a category of how a location of said 
asset for tax and/or insurance 
reporting purposes may be 
determined; 




(3) if, in step (2), said asset 
meets said set of criteria 
, corresponding to one of said queries, 
running data corresponding to said 
asset through an audit customized to 
said corresponding category to 
determine a location of said assetfor 
tax and/or insurance reporting 
purposes; 


Exhibit D, page 2, lines 23-25. 


(4) if, in step (3) a location is 
determined, assigning said 
determined location to said asset for 
tax and/or insurance reporting 
purposes; 


Exhibit D, page 2, lines 23-25. 


(5) it, in step (3), a location is 
not determined issuing an error 
notification; and 




(6) if, in step (2), if said data for 
said asset does not meet said criteria 
of any of queries, issuing an error 
notification. 


Exhibit D, page 2, lines 23-25. 






9. The computer readable 
product of claim 8 wherein instruction 
(4) further comprises instructions for 
transmitting said determined location 
for tax and/or insurance reporting 
purposes to said external software. 


Exhibit B, page 1, third paragraph, 
beginning with "Based on Input fields, 
location ... ". 






1 0. The computer readable 

nrnrli lof of oloim ft vn/hornin In 
piUUUUl Ul Uldllll O Wl IfcJI clll, 111 

instruction (2), each of said queries 
comprises at least one criterion to 
which said data for said asset must 
match. 


Exhibit D, page 2, lines 20-21. 






1 1 . The computer readable 


Exhibit D, page 2, lines 21-22. 
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product of claim 1 0 wherein, in 
instruction (2), said data for said 
asset is run through said plurality of 
queries hierarchically, wherein, when 
said asset meets set of criteria of a 
particular query, said asset data is 
noi run tnrougn any queries ordered 

lUWcl III odlU I llcl a\ Ut ly . 








12. The computer readable 
product of claim 11 wherein said 
transaction comprises a transfer or 
capitalization. 


Exhibit D, page 2, lines 14-16. 






1 3. The computer readable 
product of claim 1 1 wherein said error 
notification issued by instruction (5) 
indicates that the asset met said set 
of criteria corresponding to one of 
said categories, but was not assigned 
a location for tax and/or insurance 
reporting purposes. 


See claim 1, step (5) discussion in this 
table. 






14. The computer readable 
product of claim 13 wherein said error 
notification issued by instruction (5) 
further indicates which of said at least 
one criterion caused said error. 


See claim 1, step (5) discussion in this 
table. 






10. i ne computer readable 
product of claim 13 wherein said error 
notification issued by instruction (6) 
indicates that said asset did not meet 
said criteria corresponding to any 
L/ctit^y ui y. 


txhibit D, page 2, lines 22-25. 






1 6. The computer readable 
product of claim 8 wherein instruction 

( *\\ rnmnriQPQ ri^t^r^tinn a recall frnm 
^ i j v-fi-M 1 1 [ji loco uC/LCuui ly d L/d 1 1 1 1 ui 1 1 

said external software. 


Exhibit B, page 2, third paragraph, 
beginning with "Based on Input fields, 

Inoof inn " 
lUOdUUfl ... 






1 8. The computer readable 
product of claim 8 wherein instruction 
(3) comprises accessing said data 
corresponding to said asset from at 


Exhibit D, page 2, lines 14-20. 
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least one of a database and a 
transaction record received from said 
external sonware. 








1 9. A computer system having at 
least one memory for storing data 


Inherent 


and at least one central 
processing unit for executing 
instructions, 


Inherent 


said memory storing at least 
one database containing data about a 
plurality of capitalized fixed assets, 


Exhibit B, See, e.g., page 3, line 1, under 
heading "Interim Location Derivation 
Process line that reads Read 
Warehouse Owner Table by Warehouse 
number and Country Code as key." 


said central processing unit 
adapted to track the location of 
capitalized fixed assets for tax and/or 
insurance reporting purposes, 


Exhibit D, page 2, lines 10-16. 


said computer system 
comprising means for recording 
transactions relating to capitalized 
fixed assets, said system further 
comprising: 


Exhibit D, page 2, lines 19-20. 


means for interfacing with 
external software to become aware of 
when a capitalized fixed asset is 
involved in a transaction; 


Exhibit D, page 2, lines 19-20. 


means responsive to said 
detection for accessing data for said 
asset and running said data through a 
plurality of queries, each query 
designed to determine if said asset 
meets a set of criteria indicative of a 
category of how a location of said 
asset for tax and/or insurance 
reporting purposes may be 
determined; 


Exhibit D, page 2, lines 19-22. 


means for running data 
corresponaing 10 saia assei mrougn 
an audit customized to said 
corresponding category to determine 
a location of said assetfor tax and/or 
insurance reporting purposes, if said 
asset meets said set of criteria 
corresponding to one of said queries; 


Exhibit D, page 2, lines 23-25. 
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means for assigning said 
determined location to said asset for 
tax and/or insurance reporting 
purposes and transmitting said 
determined location to said controller 
software, it a location is determined, 


Exhibit D, page 2, lines 23-25. 


means Tor issuing an error 
notification, if a location is not 
determined; and 


exhibit u, page Z, lines Zo-Zo. 


means for issuing an error 
notification if an asset type is not 
determined tor said asset. 


Exhibit D, page 2, lines 23-25. 






20. The computer system of claim 
19 wherein each of said queries 
comprises at least one criterion to 
which said data for said asset must 
match. 


Exhibit D, page 2, line 21. 






21 . The computer system of claim 
ex* wnerein saiu uaxa Tor said asset is 
run through said plurality of queries 
hierarchically, wherein, when said 
asset meets set of criteria of a 
particular query, said asset data is 
not run through any queries ordered 
lower in said hierarchy. 


Exhibit D, page 2, lines 21-22. 
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13. As the persons signing below, we each hereby declare that all 
statements made herein of my own knowledge are true and that all statements 
made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the 
like so made are punishable by fine or imprisonment or both, under Section 1001 
Of Title 18 of the United States Code, and that such willful statements may 
jeopardize the validity of the application or any patent issued thereon. 



Date 





Date 



Dilip J, Patel 



Date 



Diana Sinor 



)\2$16%l 3/13(09 



13. As the persons signing below, we each hereby declare that all 
statements made herein of my own knowledge are true and that all statements 
made on information arid belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the 
like so made are punishable by fine or imprisonment or both, under" Section 1001 
of Title 18 of the United States Code, and that such willful statements may 
jeopardize the validity of the application or any patent issued thereon. 



Date John S. Brown 





Date 



Diana Sinor 
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13, As the persons signing below, we each hereby declare that all 
statements made herein of my own knowledge are true and that all statements 
made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the 
like so made are punishable by fine or imprisonment or both, under Section 1001 
of Title 18 of the United States Code, and that such willful statements may 
jeopardize the validity of the application or any patent issued thereon. 



Date 



John S. Brown 




Date 



Dilip J. Patel 
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EXHIBIT A 



TAX LOCATION ASSIGNMENT REQUIREMENTS 



Created By; 
i,a.si Changed By: 
Category: 
Sub Category: 




hi 06:33 P.M 



»m 12:11 PM 



Requirements - US 

Tax Location Assignment 



System Component Controllers^Capitalizations 



Contact Listing 

• PI: Sim Brown 

• SI: Dilip Patel 

• AD: 



I. OVERVIEW 

Determining an asset's location probably seems like a simple and rather insignificant matter on the surface. 
After all, it should be as easy as asking the asset owner to report the asset's location at the time of its purchase and 
capitalization or transfer. However, IBM's asset tracking systems have traditionally been maintained separately 
from their requisition, capitalization and transfer functions. This separation of functions has historically prevented 
the requester from identifying the asset's intended owner much less its final destination. As a result of this system 
limitation, the asset system architects have been forced to resort to a rather convoluted and confusing series of 
defaults to determine an asset's location. These defaults, although fairly comprehensive, have often resulted in 
invalid asset location assignments. 

The significance of these erroneous assignments is not apparent if you consider the situation from a purely 
accounting perspective. After all, the most important piece of inventory information is the asset owner's serial 
number not the physical location of the asset. However, the asset's location is easily the most significant piece of 
tax information maintained within our asset system. The asset's location is used when calculating State Income Tax, 
Personal Property Tax, Sales Tax, Use Tax and various franchise taxes. Since the right to tax citizens within the US 
is a right that was originally given exclusively to the states and municipalities, our tax law varies extensively from 
state to state, even from city to city. An erroneous tax location assignment can easily result in the overpayment of 
any number of taxes. As such, it is crucial that the next release of our asset system include a commitment to 
deriving and maintaining the highest quality of location information available given the limitations of our requisition 
systems. 

IBM's requisition systems and methodologies vary depending on the type of equipment that is being ordered 
and the division placing the order. These requisition systems are not standardized especially when considering the 
type of information the requesters are asked to provide. Some requisition tools require the requester to enter an IBM 
customer number and very little additional information. Other tools ask the requester to enter ship to information 
and their employee serial number as well as their IBM customer number. In some cases, the IBM customer number 
is not required at all. Instead, the requisition tool relies on the requester to enter shipping and billing account 
information. Due to the variety information being solicited at the time the order is placed it is impossible to develop 
a single, comprehensive approach to tax location assignment. Instead the challenge has been to derive the tax 



location based on the most reliable piece of location information provided on the record. 

In response to this challenge, the current system architects focused their efforts on developing a derivation 
process based on direct asset owner innut rather than attempting to derive the asset's location during the 
capitalization process. Since this input could not be solicited at the point of requisition, the developers designed a 
back end process based on asset owner input from the Property Control Facility (PCF). The Property Control 
Facility's functionality is based almost entirely on asset owner input. As such, requesting location information from 
the asset owners was a simple matter of adding a notifier to the system. After an asset is capitalized and reported to 
the Property Control Facility, a notifier is sent to the asset owner soliciting information regarding the asset's 
location. Once the asset owner inputs the location information, the updated information is loaded to the PCF 
Register Table. This table is the primary source of input for the current tax location derivation program (CR07). 

From a purely theoretical stand point, the tax location methodology laid out by the previous system architects 
should result in the most reliable tax location assignment available because it is based on the asset owner's input. In 
practice, though, this strategy has proven to be unreliable and inconsistent. There are a number of reasons why the 
current tax location strategy has not delivered the expected results. These reasons range from timing variances to 
invalid asset owner assignments. However, the single most pervasive problem in obtaining a valid tax location 
using the current tax location assignment strategy is simply lack of asset owner input. In short, when the asset 
owners receive notifiers from the Property Control Facility asking for location information, the majority of them 
simply do not respond. When the requested location information updates are not made, the location information 
must be derived. 

The current tax location derivation program (CR07) is based on a hierarchy of defaults. This default tax 
location information is prioritized in order of its perceived reliability. The default hierarchy is applied to all assets 
regardless of asset type or capitalization source. Under this system, for example, facility number is considered the 
most reliable piece of tax location information for everything from buildings to data processing equipment. On its 
face, this assumption does not seem problematic. However, when considering the various tracking and 
capitalization methodologies used for buildings versus data processing equipment, it is obvious that assigning a 
single tax location methodology to be applied to all types of equipment will invariably result in erroneous tax 
location assignments. 

Faulty default logic is not the only problem associated with the current tax location derivation program. In 
addition to establishing a single hierarchy of location information for all asset types, the program also bases this 
hierarchy on the false assumption that the Property Control Facility is the most reliable source of location 
information for all types of equipment. Although a rational argument could be made to support this assumption for 
most types of equipment, data processing equipment, specifically, has traditionally been tracked on the AAS asset 
management system. The AAS asset management system tracks all data processing equipment ordered internally. 
This system is used for property control, but its primary function is parts maintenance, warehouse administration 
and account billing. The additional functionality provided by the AAS asset management system is critical to the 
business; as such, updating asset information on AAS is often more important to IBM's internal customers than 
updating the same information on PCF. Considering the customers' priorities, an argument could easily be made 
that the AAS asset management system is likely to have the most updated location information on internally 
procured data processing equipment. Since the current tax location derivation program places more emphasis on 
information from the Property Control Facility than AAS, it is clear that the tax location assignments of internally 
procured data processing equipment are questionable under the existing methodology. 

In addition to the questionable tax location assignment of internally procured data processing equipment, the 
current tax location derivation program has another, more significant flaw. The program's assumption that the 
Property Control Facility is the most reliable source of location information is based on the invalid conclusion that 
asset owner's usually respond to the system notifier requesting location information. History has shown that this 
conclusion is false. The majority of asset owners do not respond to the system notifier requesting location 
information, as a result the Property Control Facility is never updated with location information from the asset 
owner. Without updated information from the Property Control Facility, the fields on the PCF Register that 
generate the tax location assignment remain blank. When the current tax location derivation program encounters 
blanks in these key fields, it often resorts to assigning the tax location based on a default location assigned at the 



division level. This default division logic does not take into consideration any of the tax location information that 
may have been available at the time of capitalization. As a result, the existing tax location methodology's reliance 
on' information from the Property Control Facility often results in a default tax location assignment that is less 
accurate than the tax location that could have been established at the point of capitalization. 

Realizing that the current tax location methodology does not take advantage of all of the information available 
at the point of capitalization, the system architects have proposed an alternate tax location strategy to optimize the 
use of this information. The strategy is fairly simple. In short, the system architects are proposing that the tax 
location be derived at the point of capitalization, establishing the most reliable default value available. After the 
asset is capitalized and the default tax location is established, the asset owner will still have the ability to update the 
location information if they choose to. Moving the default tax location derivation process to the initial capitalization 
phase allows the system architects to customize the default assignment process for different types of equipment from 
different capitalization sources. By customizing the tax location derivation strategy by asset type and capitalization 
source, the system architects afford the tax customers the ability to assess what is the most valuable piece of tax 
location information available and base the default assignment on that information. As a result, the default tax 
location assignment is based on the highest quality of tax location information available at the point of 
capitalization, eliminating the need for generic default logic based on the asset's division. 

In addition to the elimination of division level default logic, the introduction of this new tax location 
methodology will insure that every asset has a valid tax location assigned to it at the point of capitalization. This 
assurance may seem an obvious result of any well developed tax location strategy. However, the current tax 
location strategy was unable to achieve one hundred percent tax location assignment even considering the six levels 
of defaults it employed. Its failure to meet this goal resulted in approximately two thousand assets annually that had 
to be manually assigned a tax location at year end. This manual assignment process was both time consuming and 
somewhat unreliable. With the adoption of the new tax location methodology this tax exposure will be resolved and 
the need to establish the most reliable default tax location available will be addressed. 



II. DATA PROCESSING EQUIPMENT 

A. INTERNALLY MANUFACTURED DATA PROCESSING EQUIPMENT 
1. CAPITALIZATIONS 

There are four different capitalization sources for internally manufactured dataprocessing equipment - ICF, FDS, 
WIP and MTC. Each of these sources provides unique location information at the point of requisition. ICF and 
FDS, for example, rely on customer number information for location derivation. While WIP and MTC 
capitalizations provide IBM employee serial number information that could be used for location derivation. When 
presented with these varied pieces of location information, our panel of tax representatives selected customer 
number as the most reliable piece of location information for 
capitalizations of data processing equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location derivation strategy for internally manufactured data processing equipment is fairly simple. 
Based on the IBM customer number provided on the inbound capitalization record, the state/city/county code 
should be extracted from the S A ADB .MINICMR Table. This code will need to be converted to the associated 
TAXWARE code prior to posting to the Asset Master Record. The SAP Asset System will convert the 
state/city/county code to the TAXWARE code by making a call against the TAXCALC to TAXWARE mapping 
table (see SYSTEM REQUIREMENTS for specific information on this table). 

The tax location derivation strategy as outlined above is based on the assumption that the S A ADB. MINICMR 
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table can be loaded on to theSAP Asset System. If this table proves to be too large to load, a secondary strategy 
might be considered. This alternative tax location derivation strategy would still be based on the IBM customer 
number provided on the inbound capitalization record. However, rather than extracting the state/city/county code 
from the SAADB.MINICMR Table,the TAXWARE code would be retrieved directly from the Market Place 
Profile database (see EXTERNAL DEPENDENCIES for specific information on this database). 

b. EXTERNAL DEPENDENCIES 

i. MARKET PLACE PROFILE (MPP) 

The goal of the Market Place Profile Project is to create a worldwide customer database that includes all 
IBM internal and external customers currently assigned an IBM customer number. The database is expected to 
house customer information similar to the information currently maintained on the US SAADB.MINICMR Table 
with one 

significant difference. The MPP database will list the tax location code used by the TAXWARE program whereas 
the SAADB.MINICMR's "locationcode" field contains the state/city/county code used by the TAXCALC 
program. 

As part of this project all of IBM's current customers will receive a new customer number. However, the MPP 
database will track both the new customer number and the original customer number from the SAADB.MINICMR 
Table. This feature of the MPP database will allow the system architects to build a mapping table between the 
current state/city /county code and the TAXWARE code by joining on the original IBM customer number. 

, This TAXCALC to TAXWARE mapping table is essential for yearend conversion of the US assets' tax 
location information. This tax location information is maintained on the SAADB.TLOCATION_W table and will 
need to be loaded on the Asset Master Record of every US asset that is converted. 

In addition to conversion concerns, the TAXCALC to TAXWARE mapping table will be needed to derive the 
tax location code for internally manufactured data processing equipment. The strategy for deriving 
the tax location of this type of equipment involves extracting address information and the current state/city /county 
code from the SAADB.MINICMR table. Prior to posting the tax location code to theAsset Master Record, the 
state/city/county code will need to be converted to the TAXWARE code. 

c. SYSTEM REQUIREMENTS 

i. TAXCALC TO TAXWARE MAPPING TABLE 

As described above, the TAXCALC to TAXWARE Table is needed to convert the state/city/county code 
housed on the current SAADB.MINICMR Table into a TAXWARE code that will be maintained on the Asset 
Master Record. 



EXAMPLE TABLE: 



Original Customer Number 


MPP Customer Number: 


State/City/County Code: TAXWARE Code; 


4619803 


4567890 


907865123 


050130040 


6292159 


1234567 


051234890 


101210080 


0011612 


9876543 


564312089 


040371900 



FIELD DERIVATION MATRIX: 



Field Name 


Derivation 


Original Customer Number; 


Based on Feeder Input Record 


MPP Customer Number 


Derived from the MPP Table; Based on the Original Customer Number I 


State/City/County Code 


Derived from the S AADB, MINICMR Table; Field Name = Location Code 1 


TAXWARE Code 


Derived for the MPP Table; Based on the Original Customer Number 



OPEN ISSUE: 

In cases where an asset is being maintained at a location not currently listed on the S AADB .MINICMR 
Table, the SAP Administration Team will need a contact in the SUT Department whose has access to the on-line 
TAXWARE program. The SAP Administration Team will provide the SUT Department with the new address and it 
will be the SUT Department's responsibility to provide the correct tax location code. The representative from the 
SUT Department will need to assign both a state/city/county code and an associated TAXWARE code to the new 
address so that the SAP Administration Team can add the necessary entry to the TAXCALC to TAXWARE 
Mapping Table. 

ii. CUSTOMER NUMBER TABLE 

The Customer Number Table is necessary in order to derive thebuilding number associated with the asset's 
IBM internal customer number. This building number assignment is required for all IBM internal assets in order to 
satisfy insurance and federal income tax reporting requirements. 



EXAMPLE TABLE: 



Country; 


Original Customer Number? 


Responsible Cost Center; Building Number; 


TAXWARE Code| 


US 


4619803 . j 


RKA 


PLD0501 


050130040 


US j 


6292159 


9FP 


PLB861 


101210080 


US 


0011612 


79Q 


RPL676 


040371900 



FIELD DERIVATION MATRIX: 



Field Name 


Derivation 


Country 


Hardcoded to 'US" j 


Original ; 
Customer Number! 


Based on Feeder Input Record 


Responsible Cost ' 
Center 


Derived from the S AADB. MINICMR Table; Field Name = Dept 


Building Number ; 


*Input by SAP Table Administrator; Input = Work Location Concatenated with the RE/SO 
Building Number 


TAXWARE Code; 


Extract the State/City/County Code from the S A ADB .MINICMR Table; Field Name - Location ! 
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Code. Use this value to map to the TAXWARE Code based on the TAXCALC to TAXWARE 
Mapping Table, 



OPEN ISSUE: 

The RE/SO Building Number (ex. 676) is currently maintained in any one of four address fields included on 
the SAADB.MINICMR table. Since the building information is not housed in a standard location on the table, it 
cannot be automatically derived. As such, the SAP Administration Team must look up each new customer number 
on the SAADB.MINICMR to determine the RE/SO Building Number. Once they have identified the RE/SO 
Building Number, they must access Worldwide RE/SO Building Database (see EXTERNAL DEPENDENCIES for 
Transfers) to locate the associated work location. This process is extremely manual, but the SAP Administration 
Team has agreed to accept this responsibility if an automated solution cannot be found. - In order to facilitate this 
manual process, the SAP Administration Team has requested that the spool list for the automated job that loads the 
Customer Number Table (currently job # BW07) be updated to produce a listing of all new customer numbers added 
during the load. The SAP Table Administrator will use this listing to identify which customer numbers have been 
added so that their building information can be updated in a timely manner, 

2.TRANSFERS 

There are three different transfer feeders for internally manufactured data 
processing equipment - PCF, AST, and MTT. The tax location information included on both PCF and MTT varies 
with each transfer. In some cases, the tax location information may include customer number, building number 
and/or IBM employee 

serial number. Because the tax location information is not consistent our panel of tax representatives selected a 
tiered tax location strategy. This tax location strategy is designed to look for customer number updates as the 
primary source 

for tax location derivation and use IBM employee serial number as a secondarysource. 

As for AST transfers, these transfers are keyed by changes in the AAS Status Code. 
These transfers are limited to specific changes in the AAS Status Code that indicate that the equipment has been 
returned to the plant. When such a change is reported by the AST feed, a tax location transfer is initiated to reflect 
the 

asset's new location at the plant. 

a.TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The first tier of the transfer tax location strategy for internally manufactured data processing equipment mirrors 
the tax location strategy for capitalizations. Based on the IBM customer number associated with the asset's new 
location, 

the tax location is derived by extracting the state/city/county code from the SAADB.MINICMR Table. This 
state/city/county code is then mapped to the TAXWARE code it is paired with on the TAXCALC to TAXWARE 
Mapping Table. 

This TAXWARE code is posted to the Asset Master Record overwriting the previous TAXWARE code that was 
assigned to the asset. In addition to deriving the TAXWARE code associated with asset's new location, the building 
number of that new location must also be derived. Again, the derivation strategy for IBM building assignment is the 
same process used for 

establishing the original IBM building number at the point of capitalization. The IBM customer number on the 
transfer input record is used to make a call against the Customer Number Table. This table contains a mapping of 
the 

original IBM Customer Number to the IBM building number. The new building number is extracted from the table 
and posted to the Asset Master Record. The second tier of the tax location strategy for transfers of internally 
manufactured data processing equipment is based on the IBM employee serial number the asset is being transferred 



to. The IBM employee serial number is extracted from the transfer input record. This serial number is used to make 
a call against the Worldwide RE/SO Building Database (see EXTERNAL DEPENDENCIES for 

specific information). The database provides both the TAXWARE code and the IBM building number that are 
associated with the base 

IBM employee serial number. This information is then posted to the Asset Master Record overwriting the outdated 
tax location code and building number. Finally, there is a unique tax location strategy associated with AAS Status 
Code changes reported in the AST feed. This feed tracks changes in the AAS Status and Function Code Table from 
one month to the next. One of the fields maintained on this table is the AAS Status Code. This code identifies 
changes 

in the asset's use as well as its location. The updated AST requirements include a change to the current AST feed 
logic. The new logic that will be employed in SAP Release 2.2 requires the feed to report changes in the AAS 
Status Codes for 

all assets listed on the AAS Status and Function Code Table. When an asset's AAS Status Code changes to £ 80', 
£ 82', '83', or '84', that signifies that the asset is no longer in use and it has been returned to the plant. These returns 
are 

eligible for both PPT and SUT exemptions; as such, they need to be identified and reported in the outbound PPT and 
SUT feeds. The following logic is employed to uniquely identity these assets: 

If an asset 's AAS Status Code changes to an ( 80 \ '82 ', '83 \ or '84 ' , the PCF Usage 
Code on the Asset Master Record should be updated to a 75 ' to reflect that the 
asset is now in storage. In addition, the AAS Status Code on the Asset Master 
Record should be overwritten with the new status of '8x \ Finally, the tax 
location of the asset should be amended to identify its new location at the 
plant. In order to update the tax location, the following derivation process 
must be used: extract the PLANT JDF_CONTROL 'from the SAADB. ST A T_FUNC 
Table; use this value to make a call against the Plant of Control Table (see 
SYSTEM REQUIREMENTS for a complete description of this table); from the 
Plant of Control Table derive the IBM building number and the TAXWARE code 
associated with the plant location; post the updated TAXWARE code and IBM 
building number to the Asset Master Record. 

b.EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

This database is a listing owned by RE/SO and maintained on Lotus Notes. It contains a record of all inactive 
and active buildings owned or leased by IBM on a worldwide basis. The database houses a wide variety of 
information on each building including the building's address, the building's use, the work location of the building, 
whether it is owned or leased, lease information for leased locations, the responsible division, the inactive or active 
status of the building as well as the date the status of the building changed. In addition to maintaining this 
information, the owner of the database, John E. Miller in RE/SO, has agreed to add a new field to the database that 
will house the TAXWARE code associated with the location of each building. This agreement by the database 
owner is critical to our tax location strategy. Every type of asset that bases its tax location derivation on the IBM 
employee serial number will be making a call against Worldwide RE/SO Building Database to retrieve the IBM 
building number and the associated TAXWARE code. 



ii.IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

In addition to its Worldwide Building Database, the RE/SO organization is in the process of mapping the 
physical location of every IBM employee to an existing IBM facility. This information is currently being 
maintained on an MVS/DB2 platform on a site by site basis. The database owner, John E.^Miller, has indicated that 
the employee information will be added to the existing Worldwide RE/SO Building Database on Lotus Notes by 
yearend 2000. At this time, he suggested that all of the Americas would be on this integrated database and the 
EMEA would be migrated to this platform sometime in 2001. The timing of inclusion of the IBM employee 
location information is critical to our project. Since our strategy is predicated on the ability to match the IBM 



employee serial number on the input records against the Worldwide RE/SO Building Database, RE/SO's failure to 
integrate the IBM employee information into their database by yearend 2000 would invalidate 90 percent of our tax 
location derivation efforts. Because of our obvious dependency on RE/SO's efforts, the SAP 
Administration Team's Management has asked that the SI Team obtain a Document of Understanding from the 
RE/SO management in support of our project. 

iii.MARKET PLACE PROFILE (MPP) 

As with capitalization of internally manufactured data processing equipment, the tax location derivation 
strategy for transfers of this type of equipment is dependent upon the Market Place Profile Worldwide Customer 
Database Project. The dependency upon this external project is explained in detail under the CAPITALIZATIONS - 
EXTERNAL DEPENDENCIES ' 
portion of this sub topic. 

c. SYSTEM REQUIREMENTS 

i. PLANT OF CONTROL TABLE 

The Plant of Control Table is required in order to derive the tax location 
of internally manufactured equipment that has been returned to the plant. This table uses the 
4 PL ANT_OF_C ONTRO L 5 value from the S AADB . STATJFUNC Table to derive the associated IBM building 
number and TAXWARE code. 



EXAMPLE TABLE: 



Country"; 


Plantj 


Name 


Buildingj 


TAXWARE Code 


US 


983 j 


San Jose PLD050; 


050130040 


US 


988 ; 


Raleigh \ 


RPL202 040371900 


US 992 j 


Endicott PLE041 j 


201340987 



FIELD DERIVATION MATRIX: 



Field Name 


Derivation 


Country { 


Hardcodedto 'US' 


Plant 


Derived from SAADB.STAT FUNC Table where the Field Name = PLANT OF CONTROL 


Name 


Input by SAP Table Administrator 


Building 


Input by SAP Table Administrator based on contact with the PPT Department 


TAXWARE 
Code 


Input by Table Administrator based on the Building Number by referencing the Worldwide 
RE/SO Building Database 



OPEN ISSUE: 

The Plant of Control Table is being maintained as part of the current SAP Release. This table contains 
basically the same information as the information that will be required in SAP Release 2.2. The two major 
exceptions are that the table includes facility number rather than building number and the state/city/county code 



rather than the TAXWARE 

code. This information will need to be converted to facilitate the initial set up of the Plant of Control Table. Since 
the current table only has eight entries, the initial set up of the Plant of Control Table will require only a minimal 
effort. It is mentioned here for the sake of completeness. 

ii. TAXCALC TO TAXWARE MAPPING TABLE 

The requirements for this table are described in full under the SYSTEM REQUIREMENTS section of the 
CAPITALIZATIONS portion of this sub section. 

iii. CUSTOMER NUMBER TABLE 

The requirements for this table are described in full under the SYSTEM REQUIREMENTS section of the 
CAPITALIZATIONS portion of this sub section. 

B . .EXTERNALLY MANUFACTURED DATA PROCESSING EQUIPMENT 
1. CAPITALIZATIONS 

There are three capitalization sources of externally manufactured data processing equipment - Accounts 
Payable, WIP, and MTC. The tax location information available on the Accounts Payable feed is much more 
limited than 

the information that could be required as part of the manual WIP and MTC processes. As a result, the tax location 
derivation process for all three feeds is based on the information currently available on the Accounts Payable 

inbound file. Basically, there are two pieces of location information available on this feed - the requester's IBM 
employee serial number and the department owning. Given these choices, our panel of tax representatives chose to 

implement a two tiered tax location derivation strategy using the requester's IBM employee serial number as the 
primary source of tax location information 
and the department owning as a secondary source. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of externally manufactured data processing equipment relies 
exclusively on look ups against the Worldwide RE/SO Building Database. This database integrated with the RE/SO 
Space Tracking Database will allow our system architects to obtain the TAXWARE code and the IBM building 
number for an asset based on the IBM employee serial number of the requester. Using the requester's serial number, 
the system architects will be able to determine the closest office location, including building number and work 
location, of the employee in question. This location information can then be applied to the asset and posted to the 
Asset Master Record. Although it is unlikely that the 

equipment will be located in the requester's office, it is probably located in the same tax jurisdiction. Therefore, our 
panel of tax representatives felt that the requester's location was the best default tax location for externally 
manufactured data processing equipment. Since the majority of this type of equipment will be capitalized 
directly from the Accounts Payable feed, our panel of tax representatives selected a secondary tax location strategy 
to limit the number of errors produced 

by this feed. The secondary tier of this strategy relies on the department owning indicated on the record. Based on 
the department owning, the strategy calls for the system to do a look up against Bluepages to determine the IBM 
employee serial number of the manager of the department in question. Once the manager's IBM employee serial 
number has been 

derived, that serial number should be used to reference the Worldwide RE/SO Database to determine the manager's 
office location. Based on the manager's work location, the Asset Master Record can be updated with the 
corresponding TAXWARE Code and IBM building number. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 



c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
both the Worldwide RE/SO Building Database and Bluepages. 

2.TRANSFERS 

There are two different transfer feeders for externally manufactured data processing equipment - PCF and 
MTT. The tax location information included on both PCF and MTT varies with each transfer. However, in all cases 
where the 

location of the asset changes theTBM employee serial number of the owner also changes. Given this consistency, 
our panel of tax representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the tax 
location of transferred externally manufactured data processing equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of externally manufactured data processing 
equipment relies exclusively on calls against the Worldwide RE/SO Building Database. This database integrated 
with the 

RE/SO Space Tracking Database houses the closest office location of every IBM employee in the United States. By 
cross-referencing this informationagainst the 'transfer to' IBM employee serial number provided on the input file, 
the system architects can derive both the TAXWARE Code and the IBM building number. After this information is 
extracted from the Worldwide RE/SO Building Database, the tax location information on the Asset Master Record 
can be overwritten with the updated 'transfer to' location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY 
MANUFACTURED DATA PROCESSING EQUIPMENT - EXTERNAL DEPENDENCIES portion of this 
document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 

C. RENTAL DATA PROCES SING EQUIPMENT 

1. CAPITALIZATIONS 

There is only one capitalization source of rental data processing equipment - ICF. The ICF capitalization feed 
contains a limited amount of tax location information. Basically, the only viable location information on this feed is 
restricted to customer number. Considering this obvious limitation, our panel of tax representatives selected 
customer number as the basis for tax 
location derivation for all rental data processing equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location derivation strategy for rental data processing equipment is exactly the same as the tax location 
strategy for internally manufactured data processing equipment. Based on the IBM customer number provided on 
the inbound capitalization record, the state/city/county code can be derived from the S A ADB .MINICMR Table. 
This code will then be converted to the associated TAXWARE code by referencing the TAXCALC to TAXWARE 
mapping table (see INTERNALLY MANUFACTURED DATA PROCESSING EQUIPMENT - SYSTEM 
REQUIREMENTS for details on this table). Once this conversion is complete, the Asset Master Record can be 
updated with the tax location information. 
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As with internally manufactured data processing equipment, there is an open issue concerning the required 
derivation of the rental asset's building number. Because the IBM building number information can be maintained 
in any one of four address fields on the SAADB.MINICMR table, it is not possible to derive the building number 
based on a direct call 

against the table. Instead the building number must be derived by referencing the Customer Number Table (see 
INTERNALLY MANUFACTURED DATA PROCESSING EQUIPMENT - SYSTEM REQUIREMENTS for 
details of this 

table). The Customer Number Table includes the IBM customer number and its associated IBM building number. 
However, the present strategy includes a requirement for the SAP Administration Team to do a manual mapping of 
customer numbers to IBM building numbers based on queries against the SAADB.MINICMR table. This manual 
process has been referred 

to the SI Team for alternative approaches that are more automated in nature. 

b. EXTERNAL DEPENDENCIES 

i. MARKET PLACE PROFILE (MPP) 

*' The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

1. CUSTOMER NUMBER TABLE 

The specifics of this table are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - SYSTEM REQUIREMENTS portion of this document. 

ii. TAXCALC TO TAXWARE MAPPING TABLE 

The specifics of this table are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - SYSTEM REQUIREMENTS portion of this document. 

2. TRANSFERS 

As with capitalizations, there is only source of transfers of rental data processing equipment - AST. The AST 
feed is based on a comparison of changes in the SAADB.STATJFUNC Table from one month to the next. This 
table contains a listing of all internally owned data processing equipment tracked on the AAS system including 
rental equipment. Again, the only viable piece of location information available on the SAADB.STATJFUNC table 
is the IBM customer number assigned to the asset. As such, our panel of tax representatives selected customer 
number as the basis for the default tax location assignment of all transfers of rental data processing equipment. 

a.TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location derivation strategy for transfers of rental data processing equipment is exactly the same as the 
tax location strategy for capitalizations of rental data processing equipment. Based on the IBM customer number 
provided on the inbound capitalization record, the state/city/county code can be derived from the 
SAADB.MINICMR Table. This 

code will then be converted to the associated TAXWARE code by referencing the TAXCALC to TAXWARE 
mapping table (see INTERNALLY MANUFACTUREDDATA PROCESSING EQUIPMENT - SYSTEM 
REQUIREMENTS for details on this 

table). Once this conversion is complete, the Asset Master Record can be updated with the tax location information. 
As with internally manufactured data processing equipment, there is an open issue concerning the required 
derivation of the rental asset's building number. Because the IBM building number information can be maintained 
in any one of four address fields on the SAADB.MINICMR table, it is not possible to derive the building number 
based on a direct call 

against the table. Instead the building number must be derived by referencing the Customer Number Table (see 
INTERNALLY MANUFACTURED DATA PROCESSING EQUIPMENT - SYSTEM REQUIREMENTS for 
details of this 

table). The Customer Number Table includes the IBM customer number and its associated IBM building number. 



However, the present strategy includes a requirement for the SAP Administration Team to do a manual mapping of 
customer numbers to IBM building numbers based on queries against the SAADB.MINICMR table. This manual 
process has been referred 

to the SI Team for alternative approaches that are more automated in nature. 

b. EXTERNAL DEPENDENCIES 

i. MARKET PLACE PROFILE (MPP) 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

i. CUSTOMER NUMBER TABLE 

The specifics of this table are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - SYSTEM REQUIREMENTS portion of this document. 

ii. TAXCALC TO TAXWARE MAPPING TABLE 

The specifics of this table are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - SYSTEM REQUIREMENTS portion of this document. 

III. PC EQUIPMENT 

A. INTERNALLY MANUFACTURED PC EQUIPMENT 
1. CAPITALIZATIONS 

There are four capitalization sources of internally manufactured pc equipment - FDS, PCW, WIP, and MTC. 
The tax location information available on the FDS feed is limited to customer number and, in some cases, IBM 
employee 

serial number. The PCW feed, however, contains both customer number and IBM employee serial number as well 
as the ship to zip code and the department using. Finally, the WIP and MTC feeds contain a variety of information 
depending on what is entered by the cap accountant at the point of capitalization. In all cases, though, IBM 
employee serial number is required for capitalizations of internally manufactured pc equipment originating from 
these feeds. Since IBM employee serial is the only piece of tax location information that is common to all four 
capitalization sources of this type of equipment, our panel of tax representatives selected the IBM employee serial 
number as the basis for tax location of internally manufactured pc equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of internally manufactured pc relies exclusively on look ups against the 
Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking Database will 
allow our system architects to obtain the TAXWARE code and the IBM building number for an asset based on the 
IBM employee serial number on the input record. Using the IBM employee serial number, the system architects 
will be able to determine the closest office location, including building number and work location, of the employee 
in question. This location information can then be applied to the asset and posted to the Asset Master Record. In the 
case of capitalizations of internally manufactured pc equipment originating from the FDS feed, the IBM employee 
serial number is not available on the input file. The only information available on this file is the IBM customer 
number. In order to derive the IBM employee serial number from this information, the customer number should be 
used to reference the AED Table (see SYSTEM REQUIREMENTS for specific information about this table). This 
table provides a mapping of internal customer numbers to 

IBM employee serial numbers. Once the IBM employee serial number is derived based on this mapping, the tax 
location of the equipment can be detennined by cross-referencing the IBM employee serial number against the 
Worldwide RE/SO Building Database. This methodology follows the same logic as the tax location derivation for 
all other internally 

manufactured pc equipment as described above. 
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b.EXTERNAL DEPENDENCIES 



i. WORLD WIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. OIBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

i. AED TABLE 

The AED Table is required in order to derive the tax location of internally manufactured pc equipment that is 
capitalized via the FDS feed.This table maps the internal customer number from the input file to the IBM employee 
serial number of the employee who requested the customer number. 
1 EXAMPLE TABLE: 



Countryj Customer Number- Employee Serial Number! 


US 


001045 


443700 


US \ 


002334 ! 


573391 ! 


us 


000456 


024727 



FIELD DERIVATION MATRIX: 



Field Name 


Derivation 


Country 


Hardcoded to 'US' 


Customer Number 


Manually Input by IGS Contact Based on Approved AEFORMS from the Bethesda Branch 
Office 


Employee Serial 
Number 


Manually Input by IGS Contact Based on Approved AEFORMS from the Bethesda Branch 
Office, Value Equals the Requester of the AEFORMS 



1 



OPEN ISSUE: 

At the time these requirements were finalized, the decision as to whether AED Table or the PACT Table would 
be used to capitalize IGS assets had not been made. Regardless of which table is selected, a mapping of internal 
customer numbers to IBM employee serial numbers needs to be provided to support the tax location strategy for 
internally manufactured pc equipment. 

2. TRANSFERS 

There are two different transfer feeders for internally manufactured pc equipment - PCF and MTT. The tax 
location information included on both PCF and MTT varies with each transfer. However, in all cases where the 
location of the asset 

changes the IBM employee serial number of the owner also changes. Given this consistency, our panel of tax 
representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the taxiocation of 
transferred externally manufactured data processing equipment. 
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a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of internally manufactured pc equipment relies 
exclusively on calls against the Worldwide RE/SO Building Database. This database integrated with the RE/SO 
Space Tracking Database houses the closest office location of every IBM employee in the United States. By cross- 
referencing this information against the 'transfer to' IBM employee serial number provided on the input file, the 
system architects can derive both the TAXWARE Code and the IBM building number. After this information is 
extracted from the Worldwide 

RE/SO Building Database, the tax location information on the Asset Master Record can be overwritten with the 
updated 'transfer to 5 location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

. There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 

B. EXTERNALLY MANUFACTURED PC EQUIPMENT 

1. CAPITALIZATIONS 

There are three capitalization sources of externally manufactured pc equipment - Accounts Payable, WIP, and 
MTC. The tax location information available on the Accounts Payable feed is much more limited than the 
information that could be required as part of the manual WIP and MTC processes. As a result, the tax location 
derivation process for all three feeds 

is based on the information currently available on the Accounts Payable inbound file. Basically, there are two 
pieces of location information available on this feed - the requester's IBM employee serial number and the 
department 

owning. Given these choices, our panel of tax representatives chose to implement a two tiered tax location 
derivation strategy using the requester's IBM employee serial number as the primary source of tax location 
information 

and the department owning as a secondary source. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of externally manufactured pc equipment relies exclusively on look 
ups against the Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking 
Database will allow our system architects to obtain the TAXWARE code and the IBM building number for an asset 
based on the IBM employee serial number of the requester. Using the requester's serial number, the system 
architects will be able to determine the closest office location, including building number and work location, of the 
employee in question. This 

location information can then be applied to the asset and posted to the Asset Master Record. Since the majority of 
externally manufactured pc equipment will be capitalized directly from the Accounts Payable feed, our panel of tax 
representatives selected a secondary tax location strategy to limit the number of errors produced by this feed. The 
secondary tier of this strategy relies on the department owning indicated on the record. Based on the 
department owning, the strategy calls for the system to do a look up against Bluepages to determine the IBM 
employee serial number of the manager of the department in question. Once the manager's IBM employee serial 
number has been derived, that serial number should be used to reference the Worldwide RE/SO Database to 
determine the manager's office location. Based on the manager's work location, the Asset Master Record can be 
updated with the corresponding TAXWARE Code and IBM building number. 
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b. EXTERNAL DEPENDENCIES 



1. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
both the Worldwide RE/SO Building Database and Bluepages. 

2. TRANSFERS 

There are two different transfer feeders for externally manufactured pc equipment - PCF and MTT. The tax 
location information included on both PCF and MTT varies with each transfer. However, in all cases where the 
location of the asset 

changes the IBM employee serial number of the owner also changes. Given this consistency, our panel of tax 
representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the tax location of 
transferred externally manufactured pc equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of externally manufactured pc equipment relies 
exclusively on calls against the Worldwide RE/SO Building Database. This database integrated with the RE/SO 
Space Tracking Database houses the closest office location of every IBM employee in the United States. By cross- 
referencing this information against the 'transfer to' IBM employee serial number provided on the input file, the 
system architects can derive both the TAXWARE Code and the IBM building number. After this information is 
extracted from the Worldwide 

RE/SO Building Database, the tax location information on the Asset Master Record can be overwritten with the 
updated 'transfer to' location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIESportion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

,. There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 

C. LOANER, DEMONSTRATION, AND TRIAL EQUIPMENT 
1. CAPITALIZATIONS 

There are only two capitalization sources of loaner, demonstration and trial equipment - WIP and MTC. 
Although, both the WIP and MTC feeds can be customized to include a myriad of tax location information, the only 
significant piece of data is the loaner number on the record. Since loaner, demonstration, and trial equipment is 
often housed in a different tax jurisdiction than that of the asset owner, the asset owner's IBM employee serial 
number is not an appropriate basis for tax location derivation. As such, another tax location derivation strategy had 
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to be developed. The approach agreed upon by our panel of tax representatives is based on the creation of a series of 
ten digit numbers called loaner numbers. These loaner numbers represent the customers' addresses where the 
equipment is located. It is the 

responsibility of the loaner pool administrators to maintain the listing of loaner numbers and their corresponding 
addresses. When a piece of loaner, demonstration or trial equipment is capitalized, the. WIP accountant must obtain 
the associated loaner number from the loaner pool administrator in order to complete the capitalization via the CO 
module or via an MTC file. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of loaner, demonstration or trial equipment relies exclusively on 
look ups against the Loaner Number Table (see SYSTEM REQUIREMENTS for specific information about this 
table). 

Based on the loaner number, the system architects can retrieve the TAXWARE code associated with the asset's 
location and post it to the Asset Master Record. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the cooperation of the loaner pool administrators and their willingness to 
maintain a loaner number listing. 

c. SYSTEM REQUIREMENTS 

i. LOANER NUMBER TABLE 

The Loaner Number Table is required in order to derive the tax location of loaner, demonstration and trial 
equipment that is capitalized via the WIP and MTC feeds. This table maps the loaner number from the input file 
to the 

TAXWARE code associated with the asset's physical address. 



Country 


Loaner 
Number 


Company Name 


Street Address 

I 


Postal 
Code 


TAXWARE 
Code 


US 


001045 


XACT, Inc. | 


1445 Macarthur Drive; Suite 

244 j 


75007 • j 


421130480 


US j 


002334 I 

j 


ADT Security Systems | 


430 Oak Grove Street; Suite 204 j 


55403 


220530650 


US ! 

i 


000456 

_ J 


Ability Building 
Center 


1911 14th Street NW j 


55903 j 


221090900 



FIELD DERIVATION MATRIX: 



Field Name | 


Derivation 


Country 


Hardcoded to 'US' 


Loaner Number j 


Manually Input by SAP Administrator - Sequential Numbering Scheme 


Company Name j 


Manually Input by SAP Administrator Based on Lotus Note from Loaner Pool Administrator 


Street Address j 


Manually Input by SAP Administrator Based on Lotus Note from Loaner Pool Administrator 


Postal Code 


Manually Input by SAP Administrator Based on Lotus Note from Loaner Pool Administrator 
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TAXWARE 
Code 



Manually Input by SAP Administrator - Coordination with PPT Required to Assign TAXWARE 
Code 



OPEN ISSUE: 

The SAP Administration Team has expressed a concern regarding the amount of manual work this table will 
require in order to maintain. All possible avenues for automation should be explored. Since the loaner number 
updates are going to be sent en mass to SAP, one suggestion might be to have the loaner administrator include the 
address information on this mass update file. In theory, the system could extract the address 
information associated with the loaner number and load it to the table automatically. If this method was employed, 
the SAP Administration Team would only be responsible for entering the TAXWARE code information into 
the Loaner Table. 

2. TRANSFERS 

There are two different transfer feeders for loaner, demonstration and trial equipment - PCF and MTT. The tax 
location information included on both PCF and MTT varies with each transfer. However, in the case of loaner, 
demonstration and trial equipment one piece of information is required on all transfers - the loaner number. These 
transfers are initiated by the loaner pool administrators either by submitting monthly update files or initiating 
transfers via PCF. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of loaner, demonstration and trial equipment relies 
exclusively on calls against the Loaner Number Table. Based on the 'transfer to' loaner number on the input file, 
the system architects can perform a lookup against the Loaner Table and derive the associated TAXWARE Code. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the cooperation of the loaner pool administrators and their willingness to maintain a 
loaner number listing and submit the required updates. 

c. SYSTEM REQUIREMENTS 

i. LOANER NUMBER TABLE 

The Loaner Number Table is required in order to derive the tax location of loaner, demonstration and trial 
equipment that is transferred via the PCF and MTT feeds. This table maps the loaner number from the input file to 
the 

TAXWARE code associated with the asset's physical address. 
IV. MACHINERY AND EQUIPMENT 

A. INTERNALLY MANUFACTURED MACHINERY AND EQUIPMENT 
1. CAPITALIZATIONS 

, There are two capitalization sources of internally manufactured machinery and equipment - WIP and MTC. 
There is a variety of location information available on both of these feeds depending upon what the WIP accountant 
chooses to 

enter at the point of capitalization. However, there is one piece of location information that is required on all 
capitalizations of internally manufactured machinery and equipment - the asset owner's employee serial. Because 
this 

information is consistently required, our panel of tax representatives selected the IBM employee serial number as the 
basis for tax location assignment for this type of equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of internally manufactured machinery and equipment relies 
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exclusively on look ups against the Worldwide RE/SO Building Database. This database integrated with the RE/SO 
Space Tracking Database will allow our system architects to obtain the TAXWARE code and the IBM building 
number for an asset based on the IBM employee serial number of the asset owner. Using the asset owner's serial 
number, the system architects will be able to determine the closest office location, including building number and 
work location, of the employee in question. This location information can then be applied to the asset and posted to 
the Asset Master Record. 

b. EXTERNAL DEPENDENCIES 

1 . WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
both the Worldwide RE/SO Building Database and Bluepages. 

2. TRANSFERS 

There are two different transfer feeders for externally manufactured pc equipment - PCF and MTT. The tax 
location information included on both PCF and MTT varies with each transfer. However, in all cases where the 
location of the asset 

changes the IBM employee serial number of the owner also changes. Given this consistency, our panel of tax 
representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the tax location of 
transferred internally manufactured machinery and equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of internally manufactured machinery and 
equipment relies exclusively on calls against the Worldwide RE/SO Building Database. This database integrated 
with the RE/SO Space Tracking Database houses the closest office location of every IBM employee in the United 
States. By cross-referencing this information against the 'transfer to' IBM employee serial number provided on the 
input file, the system architects can derive both the TAXWARE Code and the IBM building number. After this 
information is extracted from the Worldwide RE/SO Building Database, the tax location information on the Asset 
Master Record can be overwritten with the updated 'transfer to 5 location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this, database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 

B. VENDOR RETAINED TOOLING 
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1. CAPITALIZATIONS 

There are only two capitalization sources of vendor retained tooling - WIP and MTC. Although, both the WIP 
and MTC feeds can be customized to include a myriad of tax location information, the only significant piece of data 
is the vendor number on the record. Since vendor retained tooling is often housed in a different tax jurisdiction than 
that of the asset owner, the asset owner's IBM employee serial number is not an appropriate basis for tax location 
derivation. As such, another tax location derivation strategy had to be developed. The approach agreed upon by our 
panel of tax representatives is based on the vendor number assigned by accounts payable. This vendor number 
represents the company name and physical address of the vendor who has possession of the equipment. When a 
piece of vendor retained tooling is capitalized, the WIP accountant must input the associated vendor number in order 
to complete the capitalization via the CO module or via an MTC file. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of vendor retained tooling relies exclusively on look ups against the 
Vendor Number Table (see SYSTEM REQUIREMENTS for specific information about this table). Based on the 
vendor number, the system architects can retrieve the TAXWARE code associated with the asset's location and post 
it to the Asset Master Record. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the manual entry of the vendor numbers by the WIP accountant at the point of 
capitalization. 

c. SYSTEM REQUIREMENTS 

i. VENDOR NUMBER TABLE 

The Vendor Number Table is required in order to derive the tax location of vendor retained tooling is 
capitalized via the WIP and MTC feeds. This table maps the vendor number from the input file to the TAXWARE 
code associated 

with the asset's physical address. 



EXAMPLE TABLE: 



; Country; 


Vendor Table 


Vendor Name 


Street Address 


Postal Code 


TAXWARE Code 


US 


000 1 023 j Onan Corp. ; 9713 Valley View Road j 


55344 


220530650 


;us 


0001534 


Jonathan Mfg Corp.: 


1101 South Acacia Ave.; 


92631 


040591310 


us 1 


0001132 j 


Amray, Inc. j 160 Middlesex Tpke j 01730 


200170075 ! 





FIELD DERIVATION MATRIX: 



Field Name 


Derivation 


Country 


Hardcoded to 'US' 


Vendor Number j 


Manually Input by SAP Administrator by Referencing Accounts Payable Vendor Table 


Vendor Name 


Manually Input by SAP Administrator by Referencing Accounts Payable Vendor Table 


Street Address \ 


Manually Input by SAP Admin istrator by Referencing Accounts Payable Vendor Table 


Postal Code 


Manually Input by SAP Administrator by Referencing Accounts Payable Vendor Table 


TAXWARE 
Code 


Manually Input by SAP Administrator - Coordination with PPT Required to Assign TAXWARE 
Code 
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OPEN ISSUE: 

The SAP Administration Team has expressed a concern regarding the amount of manual work this table will require 
in order to maintain. If possible this manual table load process should be replaced by a direct feed from Accounts 
Payable. 

2. TRANSFERS 

There are two different transfer feeders for vendor retained tooling - PCF and MTT. The tax location 
information included on both PCF and MTT varies with each transfer. However, in the case of vendor retained 
tooling one piece of information is required on all transfers - the vendor number. These transfers are initiated by the 
asset owners either by submitting an update file or initiating transfers via PCF. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

'* Like capitalizations, the tax location strategy of transfers of vendor retained tooling relies exclusively on calls 
against the Vendor Number Table. Based on the 'transfer to' vendor number on the input file, the system architects 
can perform a lookup against the Vendor Table and derive the associated TAXWARE Code. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the input of the asset owner. 

c. SYSTEM REQUIREMENTS 

i. " VENDOR NUMBER TABLE 

The Vendor Number Table is required in order to derive'the tax location of vendor retained tooling that is 
transferred via the PCF and MTT feeds. This table maps the vendor number from the input file to the 
TAXWARE code 

associated with the asset's physical address. 

V. FURNITURE AND FIXTURES 

A. INVENTORIABLE FURNITURE AND FIXTURES 

1. CAPITALIZATIONS 

There are two capitalization sources of in ven tori able furniture and fixtures -WIP and MTC. There is a variety 
of location information available on both of these feeds depending upon what the WIP accountant chooses to enter 
at the 

point of capitalization. However, there is one piece of location information that is required on all capitalizations of 
inventoriable furniture and fixtures - the asset owner's employee serial number. Because this information is 
consistently required, our panel of tax representatives selected the IBM employee serial number as the basis for tax 
location assignment for this type of equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of inventoriable furniture and fixtures relies exclusively on look 
ups against the Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking 
Database 

will allow our system architects to obtain the TAXWARE code and the IBM building number for an asset based on 
the IBM employee serial number of the asset owner. Using the asset owner's serial number, the system 
architects will be able to determine the closest office location, including building number and work location, of the 
employee in question. This location information can then be applied to the asset and posted to the Asset Master 
Record. b. EXTERNAL DEPENDENCIES 
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1. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. , SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
both the Worldwide RE/SO Building Database and Bluepages. 

2. TRANSFERS 

There are two different transfer feeders for inventoriable furniture and fixtures - PCF and MTT. The tax 
location information included on both PCF and MTT varies with each transfer. However, in all cases where the 
location of the asset 

changes the IBM employee serial number of the owner also changes. Given this consistency, our panel of tax 
representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the tax location of 
transferred inventoriable furniture and fixtures. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of inventoriable furniture and fixtures relies 
exclusively on calls against the Worldwide RE/SO Building Database. This database integrated with the RE/SO 
Space Tracking 

Database houses the closest office location of every IBM employee in the United States. By cross-referencing 
this information against the 'transfer to' IBM employee serial number provided on the input file, the system 
architects 

can derive both the TAXWARE Code and the IBM building number. After this information is extracted from the 
Worldwide RE/SO Building Database, the tax location information on the Asset Master Record can be overwritten 
with the updated 'transfer to' location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 

B. NON-INVENTORIABLE FURNITURE AND FIXTURES 

1. CAPITALIZATIONS 

There are three capitalization sources of non-inventoriable furniture and fixtures - Accounts Payable, WIP and 
MTC. The tax location information available on the Accounts Payable feed is much more limited than the 
information that could be required as part of the manual WIP and MTC processes. As a result, the tax location 
derivation process for all three feeds 

is based on the information currently available on the Accounts Payable inbound file. Given this restriction, it was 
originally proposed that the postal zip code on the accounts payable record be used to make a call against a new 
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Postal Zip Code to AUO Mapping Table. However, this strategy was based on the assumption that the postal zip 
code represented the 'ship to' postal zip code. Further investigation has determined that the zip code on the 
accounts payable record actually represents the vendor's postal zip code. As such, a strategy that relies on the zip 
code on the accounts payable record is not a 

viable tax location strategy. An alternate strategy using the same type of logic has been proposed. This strategy 
relies on the requester' s IBM employee serial number to determine the location of the requester and use that 
location to identify the default AUO department the equipment should be capitalized to. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of non-inventoriable furniture and fixtures varies depending on the 
capitalization source. For non- inventoriable furniture and fixtures capitalized via the accounts payable 
feed, the strategy is multi-tiered. First, the requester's IBM employee serial number is used to make a call against 
the Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking Database will 
allow our system architects to obtain the postal zip code of the requester's office location. That postal zip code 
could then be used 

to make a call against the Zip Code to AUO Mapping Table (specific requirements for this table are described under 
the SYSTEM REQUIREMENTS portion of this topic). Based on the postal zip code of the requester's 
location, the AUO department, the IBM building number and the TAXWARE code can be derived from this table. 
This location information can then be applied to the asset and posted to the Asset Master Record. 

For capitalizations of non-inventoriable furniture and fixtures from the WIP or MTC feeds, the strategy is much 
simpler. Since these feeds are driven by manual input, the WIP accountant will be required to check the invoice for 
the ship to zip code. Based on that postal zip code, the WIP accountant will select the corresponding AUO 
department off of the Postal Zip Code to AUO Mapping Table. This AUO department will be entered as part of the 
capitalization record. The system architects will then use the AUO department on the input record to make a call 
against the Postal Zip Code to 

AUO Mapping Table. Based on the AUO department from the input record, the IBM building number and the 
TAXWARE code can be derived. This location information can then be applied to the asset and posted to the Asset 
Master Record. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 1 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

i. POSTAL ZIP CODE TO AUO MAPPING TABLE 

This table is required in order to derive the AUO department necessary to build the lotcap inventory number on 
capitalizations of non-inventoriable equipment from the accounts payable feed. In addition to the lotcap inventory 
number creation, the table is also required to derive the IBM building number and TAXWARE code for all 
capitalizations 

of non-inventoriable furniture and fixtures. 



EXAMPLE TABLE: 



Country] Postal Zip Code! Local Division! Cost Center: 


Building Number! 


TAXWARE Code 


US 


80301 SG IZNT 


SGPLD0501 =050130040 


us 


30327 FC ! AEB j FCPLB861 


101210080 


US ; 27709 10 AG5 


10RPL676 


040371900 

i 
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us 



27712 



10 



ASO 



10RPL500 



040371901 



FIELD DERIVATION MATRIX: 



Field Name 


Derivation 


Cduntry j 


Hardcoded to 'US' 


Postal Zip Code j 


Manually Input by SAP Administration Team based on SAP Capitalization Errors 


Local Division j 


Derived from CSKS Table Based on the Cost Center 


Cost Center 


Manually Input by SAP Administration Team - Coordination with WIP Accountants Required to ! 
Set Up AUOs 


Building Number 


Manually Input by SAP Admini stration Team Based on Contact with the PPT Department 


TAXWARE 
Code 


Derived from the Building Table based on the Building Number 



1 OPEN ISSUE: 

The initial set up of this table will require coordination with the WIP accounting community to set up the AUO 
departments and the PPT department to identify the associated building numbers. In addition, research will need to 
be performed to determine which postal zip codes should be loaded to the table. This research should be based on 
the 

postal zip codes for each work location listed in the Worldwide RE/SO Building Database. 
VI. BUILDINGS AND BUILDING EQUIPMENT 
A. BUILDINGS AND BUILDING EQUIPMENT 
1. CAPITALIZATIONS 

There are only two capitalization sources of buildings and building equipment - WIP and MTC. Although, 
both the WIP and MTC feeds can be customized to include a myriad of tax location information, the only significant 
piece of data 

is the building number on the record. This building number represents the IBM building number and work location 
where the building assets are located. When buildings or building equipment are capitalized, the WIP accountant 
must input the associated building number in order to complete the capitalization via the CO module or via an MTC 
file. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

The tax location strategy for capitalizations of buildings and building equipment relies exclusively on 
look ups against the Building Number Table (see SYSTEM REQUIREMENTS for specific information about this 
table). Based 
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on the building number, the system architects can retrieve the TAXWARE code associated with the asset's location 
and post it to the Asset Master Record. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the manual entry of the building numbers by the WIP 
accountant at the point of capitalization. 

c. SYSTEM REQUIREMENTS 

i. BUILDING NUMBER TABLE 

The Building Number Table is required in order to derive the tax location of buildings and building equipment 
that are capitalized via the WIP and MTC feeds. This table maps the building number from the input file to the 
TAXWARE code associated with the asset's physical address. 



EXAMPLE TABLE: 



Country; 


Building Number' 


Work Location 


RE/SO Building Number;] Street Address (TAXWARE Code 


US 


PLD0501 


PLD 


0501 1 5600 Cottle Road |050130040 


US j 


PLB861 


PLB 861 


1000 River Street j| 10 121 0080 


US ; 


RPL676 SRPL \ 676 4407 Silicon Drive! 


040371900 



FIELD DERIVATION MATRIX: 



Field Name 


Derivation : 


Country 


Hardcoded to 'US' 


Building Number 


Work Location + RE/SO Building Number 


Work Location 


Derived from the RE/SO Worldwide Building Database; Field Name = Work Location i 


RE/SO Building 
Number 


Derived from the RE/SO Worldwide Building Database; Field Name = Building Id 


Street Address 


Derived from the RE/SO Worldwide Building Database; Field Name = Address 


TAXWARE Code 


Derived from the RE/SO Worldwide Building Database; Field Name Has Not Been 
Assigned 



OPEN ISSUE: 

The PPT Department has requested that the contents of this table be validated against the Worldwide RE/SO 
Building Database on a monthly basis. This validation job should be written to produce a report of 
discontinued facilities. This report will need to manually worked by the SAP Administration Team insuring that all 
active assets are assigned to active facilities. 

2. TRANSFERS 

There is only one transfer feeder for buildings and building equipment - MTT. The tax location information 
included on the MTT feed varies with each transfer. However, in all cases where the location of the asset changes 
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the building number of the asset also changes. Given this consistency, our panel of tax representatives 

chose the 'transfer to' building number as the basis for deriving the tax location of transferred buildings and building 

equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of buildings and building equipment relies exclusively 
on calls against the Building Table. This table maps building numbers to their associated TAXWARE code. Once 
this call 

is made based on the 'transfer to' building number, the resulting tax location information can be posted to the Asset 
Master Record. 

b. EXTERNAL DEPENDENCIES 

There are no specific external dependencies required for the implementation of this tax location strategy. The 
strategy relies completely upon the manual entry of the building numbers by the transfer accountant at the point of 
transfer. 

c. . SYSTEM REQUIREMENTS 

i. BUILDING NUMBER TABLE 

The Building Number Table is required in order to derive the tax location of buildings and building equipment 
that are capitalized via the WIP and MTC feeds. This table maps the building number from the input file to the 
TAXWARE code associated with the asset's physical address. 

VII. NON-FINANCIAL ASSETS 

A. NON-FINANCIAL ASSETS 

1.' CAPITALIZATIONS 

There is only one capitalization source for non-financial assets - MTC. There is a variety of location 
information available on the MTC depending upon what the WIP accountant chooses to enter at the point of 
capitalization. However, there is one piece of location information that is required on all capitalizations of non- 
financial assets - the asset owner's employee serial number. Because this information is consistently required, 
our panel of tax representatives selected 

the IBM employee serial number as the basis for tax location assignment for this type of equipment. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

*■ The tax location strategy for capitalizations of non-financial assets relies exclusively on look ups against the 
Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking Database will 
allow our 

system architects to obtain the TAXWARE code and the IBM building number for an asset based on the IBM 
employee serial number of the asset owner Using the asset owner's serial number, the system architects will be able 
to 

determine the closest office location, including building number and work location, of the employee in question. 
This location information can then be applied to the asset and posted to the Asset Master Record. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii, IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
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The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
both the Worldwide RE/SO Building Database and Bluepages. 

2. TRANSFERS 

There are two different transfer feeders for non-financial assets - PCF and MTT. The tax location information 
included on both PCF and MTT varies with each transfer. However, in all cases where the location of the asset 
changes the IBM employee serial number of the owner also changes. Given this consistency, our panel of tax 
representatives chose the 'transfer to' IBM employee serial number as the basis for deriving the tax location of 
transferred non-financial assets. 

a. TAX LOCATION DERIVATION STRATEGY - OVERVIEW 

Like capitalizations, the tax location strategy of transfers of non-financial assets relies exclusively on calls 
against the Worldwide RE/SO Building Database. This database integrated with the RE/SO Space Tracking 
Database 

houses the closest office location of every IBM employee in the United States. By cross-referencing this information 
against the 'transfer to' IBM employee serial number provided on the input file, the system architects can derive 
both the TAXWARE Code and the IBM building number. After this information is extracted from the Worldwide 
RE/SO Building Database, the tax location information on the Asset Master Record can be overwritten with the 
updated 'transfer to 5 location information. 

b. EXTERNAL DEPENDENCIES 

i. WORLDWIDE RE/SO BUILDING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

ii. IBM SPACE SUITE - RE/SO SPACE TRACKING DATABASE 

The specifics of this database are described in the INTERNALLY MANUFACTURED DATA PROCESSING 
EQUIPMENT - EXTERNAL DEPENDENCIES portion of this document. 

c. SYSTEM REQUIREMENTS 

There are no specific tables and other system requirements necessary for the implementation of this strategy. 
The strategy is simply predicated on the premise that the SAP system will be able to effectively make calls against 
the Worldwide RE/SO Building Database. 
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EXHIBIT B 



Tax Location Derivation (ABF) 

~4\eJac-kJ 



Created By: Diiip l J atd on 

Last Changed By. Dilip Paid on 

Cut ego ry: PFS 

Sub Categoiy: Tax Location Assignment 

.System Component Additional Bridge Functions 



1 . Location Type field is required for Web Front-end (PCF) 

2. Validity and population of TXJCD on our RESO table will be part of table load process, therefor 

blank is valid value. 

3. Work Loc. + Bldg. will be on MPP 

Main objective of Tax Location Derivation process is to derive Tax location at a time of Capitalization and /or 
Transfer of an Asset. 

Currently this process is in two part, one for non-US counties and other for the US. 

Based on Input fields, location derivation process sequentially go through conditional checks until Location is 
derived. Once the Tax Location is derived, process returns to calling controller/process the tax Location Code 
(TAXWARJE Code). When it has been determind that an error situation has been encountered that error code will be 
set here and returned to calling process. It's calling process responsibility to check the error code and take 
appropriate action. While deriving tax Location if Work Location and Building is derived, then this process will 
return Location + Building. Also Location type will be set and returned to calling process. 

Special consideration is taken for US side of the logic, is after retrieving TXJCD and before returning to controller, 
verify TXJCD exists in Taxware to Taxloc mapping table. If TXJCD does not exists or if the taxloc field is blank, 
set ERROR Code ("TXJCD does not have matching Tax location Code"). The derived TXJCD value should be 
returned to the calling program. 



There are two path to Location derivation process, One for US and the other for all other countries. To process 
whiqh side of Location Derivation, ABF will look in to Country Table to make determination to either to process 
EMEAorUS. 



Field 


Valid Values 

:>■;: :/■'}■..■■ : ■' v..: • ; : , ..• . \i •/..:,>■ ••• >.• 

'0. . ;Vy::7 / .>, . • '/V.' ' >• ^ 


Input/ 
Output 


Country Code 


Valid Country Code 




Location Type 


L,V,I,C 


I/O 


Usage Code 


15* 




Asset Class 


42, 41, OX, IX* 




Lotcap Indicator 


YorN 




Employee Serial Number 


Valid Serial 




Vendor Number 


Valid Vendor Number 





Jriant oi control 


Valid riant ot Control j 


I 


Customer Number 


Valid Customer Number ! 


I 


Work LrOC. + Building 


Valid Work Loc. + Building 


I/O 


Is n ip__to_Z/ip c o d e 


Valid Snip_to_zipcode 


I 


Loaner Number 


Valid Loaner Number 


I 


Responsible Cost Center 


Valid RCC 


I/O 


Ordering Cost Center 


Valid Cost Center 


I 


Profit Center 


Valid Profit Center (PRCTR) 


I 


Warehouse Number 


Valid Warehouse # 


I 


Owner Type for Warehouse Lookup 


WDC or WH* 


I 


Taxw Code(TXJCD) 


Valid Tax Code 


O 


Error Code 


Blank as Input/Output 

If error, Error Code will be passed back; 


o 



* These are the values that are specifically used in the derivation process. 
Note: 

1) This fields are needed by itself or with conjunction with one and another for Tax Location Derivation. 



Special consideration for US Tax Location Derivation: 

1), After retrieving TXJCD and before returning to controller, verify TXJCD exists in Taxware to Taxloc 
mapping table, 

If TXJCD does not exists, set ERROR Code for ("TXJCD does not have matching Tax location Code") 



Interim Location Derivation Process 



If LOTC AP_IND = Yes 
Do; 

Use Ship_to_Zipcode as key to read in RESO table 
If Ship_to_Zipcode found 

Retrieve TXJCD Code from RESO Table 
Set Location Jype = T /* IBM Bldg. work loc. and building */ 
Else /*** EEEERRRROOORRRR ****/ 

End; 

Else 

If Owner Jype = 'WH*' or 'WDC or 'PM' or 'HDC or f SDC 
Do; 



Read Warehouse Owner Table by Warehouse Number and Country Code as key 

If Warehouse Number and Country Code found 

Do; 

Use Work. Loc. + Bldg. as key to RESO Table 
If Found 

Retrieve and Assign TXJCD from RESO Table 
Set Location Type = T 
Else /*** EEEERRRRROOORRRR ***/ 

End; 

Else ./**** EEERRRROOOORRRR ***/ 

End; 
Else 

If Work Loc. + Bldg. NE Blank 
Do; 

Use Work Loc. + Bldg. # as key from input to read in Building (RESO) table 
If Work Loc. + Bldg. found 

Retrieve Building Information with TXJCD Code 
Set Location_Type = T 
Else/*** EEERRRRROOOORRRR ****/ 

End; 
Else 

If Ordering_Cost center NE Blank 
Do; 

Read CSKS by Ordering Center as Key 

If work. Loc. + Bldg. found 

Do; 

Use Work. Loc. + Bldg. as key to RESO table 
If Found 

Retrieve and Assign TXJCD from RESO Table 
Set Location Type = T 
Else 



; EEEEERRRRROOOOORRRRR 



End; 
Else 



; Process logic below from "Interim Blue Page"! 



End 
Else 



Process logic below from "Interim Blue Page"; 



Interim Blue Page 



If EMPLOYEESERIAL NE BLANK 
Do; 

Use Country Code to see which field will be use to get to Work Loc. + Bldg. (new field on entry 

table) 

If Intrim-derived_field = blank 
Do; 



Process logic from "Interim By Employee Serial #"j 



End; 
Else 
Do; 

Use Emp. Serial Number as Key to read in Blue Pages 

If Emp. Serial Found 

Do; 

Use Intrim-derived_fleld to retrieve Work Loc. + BIdg(from workloc_bld mapping table) 
If Intrim-derived_field found 

Use Work Loc. + Bldg. from Interim table to retrieve TXJCD from RESO Table 

If Found on RESO 
Assign TXJCD from RESO 

Set Location_type = T /* IBM Bldg. and work loc. and building */ 
Return Work. Loc. + Bldg. 
Else /* EEERRRRROOOORRRR*/ 
Else /* EEERRRRROOOOR RRR*/ 

End; 
Else 



Process logic from "Interim By Cost Center" 



End; 



End; 
Else 



Process logic from "Interim By Cost Center" 



Interim By Employee Serial Number 



If EMPLOYEE SERIAL NE BLANK 
Do; 

Use Emp. Serial Number as Key to read in Blue Pages 
If employee serial found 
Do; 

Use Work Loc + Building # from Blue Pages to read in RESO Table 
IF Work. Loc + Bldg Found 



Retrieve TXJCD Code from RESO Table 
Assign TXJCD 

Set Location_type = T /* IBM Bldg. and work loc. and building */ 
Else /** EEEEERRRRROOOORRRR **/ 
End; 

Else 

If employeeserial Not Found 
Do; 

If cost center NE BLANK 
Do; 

[Process logic from "Interim By Cost Center"] 



End; 

Else 



EEEEEERRRRRRROOOOOOORRRRRRRRR 



End; /* end of Employee serial not found */ 

End; /* end of Employee Serial # not Blank */ 



Interim By Cost Center 



If cost center NE BLANK 
Do; 

-Use cost center as key to read in Bluepages table & Retrieve Mgr.'s. Serial # for cost center . 
If Mgr.'s Serial Found then 
Do; 

If Inrim-derivedfield = Blank 

Use Work Loc. + Bldg to read RESO table 
If Found on RESO 

Assign TXJCD from RESO 

Set Locationjype = T /* IBM Bldg. and work loc. and building */ 
Return Work. Loc. + Bldg. 
Else /* EEEERRRROOOORRRR */ 

Else 

If Inrim-derived field NE Blank 

Use Intrim-derived_field to retrieve Work Loc. + Bldg(from mapping table) 
If Intrim-derived_field found 

Use Work Loc. + Building to read in RESO Table 

If Found on RESO 
Assign TXJCD from RESO 

Set Locationjype = T /* IBM Bldg. and work loc. and building */ 
Return Work. Loc. + Bldg. 

Else /* EEEERRRROOOORRRR */ 



Else/* EEEERRRRROOOOORRRRR*/ 

End; 
Else 

If Mgr.'s Serial Not Found then 
Do; 

-Use Cost Center as key to read in CSKS for Serial(NAME2) 
If Serial Found 
-Use Serial # to read Blue Pages 
Do; 

If Inrim-derivedfield — Blank 

Use Work Loc. + Bldg to read RESO table 
If Found on RESO 

Assign TXJCD from RESO 

Set Location_type = T /* IBM Bldg. and work loc. and building */ 
Return Work. Loc. + Bldg. 
Else /* EEEERRRROOOORRRR */ 

Else 

If Inrim-derived field NE Blank 

Use Intrim-derived_field to retrieve Work Loc. + Bldg(from mapping table) 
If Intrim-derived field found 

Use Work Loc. + Building to read in RESO Table 

If Found on RESO 

Assign TXJCD from RESO 

Set Location_type = T /* IBM Bldg. and work loc. and building 
Return Work. Loc. + Bldg. 
Else /* EEEERRRROOOORRRR */ 
Else/* EEEERRRRROOOOORRRRR*/ 

End; 

If Serial Not Found 
Use logic from "Interim by Default Owner (Serial #)" j 



End; /* Mgr.'s Serial Not Found */ 
End;/ * cost center NE Blank */ 



Interim by Default Owner($erial #) 



-Use Country Code to find Default Owner in Default Owner table 

If Default Owner (Serial #) found 

Do; 

-Retrieve Default Serial # and Read in Blue Pages for Intrim-derivedfield to WrkLoc.+Bldg. 
If Default Serial # Found & Work Loc. + Bldg. o Blank 
Do; 

Use Work Loc. + Bldg. as key to read in RESO Table 
If Work Loc. + Bldg. found 
Do; 

Retrieve TXJCD Code 

Set Location Type = I' /* IBM Bldg. work Loc. */ 
End; /* end of Work Loc. + Bldg. found & TXJCD Code o Blank */ 
Else /**EEEEEERRRRRRROOOOOOORRRRRRR *** */ 
End; /* end of Serial # found in Blue Pages & Work Loc. + Bldg. o Blank */ 
Else /* **** EE EE EERRR RRROOOO O OOR RRRRRR ***/ 
End; /* end of Default Owner (Serial #) found in Default Owner Table */ 



Else/***** EEEEEERRRRRRROOOOOORRRRRRR ****•/ 



Interim Process Endj 



Strategic Location Derivation Process^ 



Return to Plant 



If Usage_code = '15' 

D o; /**** For Return to plant ****/ 
-Use Plant code as key to read in P]ant_Of_control table 
if Plant_of_control found & Workjoc + BIdg. o blank 
Do; 

-Retrieve Work_loc + Bldg. Number 

-Use Workjoc + Bldg. as key to read in RESO table 

IfTXJCD Code found 

-Retrieve TXJCD Code from RESO 
-Set Locationjype = T /* IBM Bldg. and work loc. and building */ 
Else / * EEEERR RROOOORRR ***/ 
End; 

Else /* EEEERRRROOOORRR * * */ 
End; 
Else 



Rentals 



If ASSET_CLASS = '42' 
Do; 

Read ZACTLAREA by Landl to retrieve Country Code(i,e. 897 for US) 
if found 

Do; 

Use Country code + Input Customer Number & TXJCD <> Blank 



to read in ZKN A 1 (by KATR6 + ZZKV-CUSNO) 

If Customer Number found & TXJCD o blank 
Do; 

Read Customer Number in ZADRC where ZKNA1-ADRNR = 
ZADRC-ADDRNUMBER and ZADRC-NATION = ' ' 
If Customer found & ((ZADRC-ROOMNUMBER and ZADRC-BUILDING) o Blank) 
Do; /* Internal */ 

Retrieve Work Loc, Building 
Go to ZARESO to retrive TXJCD 
Set Location type = T 
End; 
else 
Do; 

Do; /* External */ 

Retrieve KN A 1 -TXJCD 
Set Location type = 'C 
End; /* external */ 
End; /* If work Loc + Bldg was blank on MPP */ 
End; /* if customer found in MPP */ 

Else/* Customer Not found */ 
if Customer is not Found 
Do; 

Use Customer Number to read in ZACUST 
If Customer Number Found & Work Loc + Bldg o Blank 
Do; 

Use Work Loc + Bldg to read in ZARESO 
If Work Loc + Bldg found in ZARESO 
Do; 

Retrieve TXJCD 
Set Location type = T 
End; 

Else/**** ERROR***/ 

End; 

— Else 



EEEEEERRRRRROOOOORRRRR 



END; /* end of customer not found or TXJCD code is blank */ 

End;/* ZACTLAREA - Country Code found */ 
Else 

/**** EERRRROOORRR Country Code Not found ****/ 
End; /* end of Asset class 42 */ 

Else 



AH Lotcaps 



If LOTCAP_IND- Yes 

Do; /***** For Lot cap *****/ 

Use Ship_to_Zipcode + Profit Center as key to read in Ship_to_Zip table 
IF Record Found 
Do; 

Retrieve Work Loc. + Building Number 
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Based on Work Loc. + Building Number, read in RESO table to (Possibly direct read of 
RESO by ZIP Code & Profit Center) retrieve TXJCD Code from RESO Table 
Set Location_type = T /* IBM Bldg. and work loc. and building */ 
End; 

Else 

Do; 

EEEEEERRRRRROOOOORRRRR) 



End; 
End; 

Else 



Warehouse} 



If Owner_type = WDC* or WH* or PM* or HDC* or SDC* 
Do; 

Read Warehouse Owner Table by Warehouse Number and Country Code as key 

If Warehouse Owner Number and Country Code found 

Do; 

Use Work. Loc + Bldg as key to RESO Table 
If Found 

Retreive and Assign TXJCD from RESO Table 
Set Location Type = T 
Else /*** EEEERRRRROOORRRR ***/ 

End; 

Else /**** EEERRRROOOORRRR ***/ 

End; 
Else 



Land & Building! 



If ASSET_CLASS - OX* or IX* 

Do; /***** Buildings & Land *****/ 

Use Work Loc. + Bldg. # as key from input to read in RESO table 
If Work Loc. + Bldg. found & TXJCD Code is <> Blank 

Retrieve TXJCD Code from RESO table 
Set Location_type - T /* IBM Bldg. */ 
Else /***** E EEEEE RRRR RRQOOOOOR RRRRRR ******/ 
End; 

Else 



Property Control (Web Front-end); 



If LOCATIONTYPE = <L7'V7'I7'C' 
Do; 

IF ey? /**** Location For Vendor ****/ 
Do; 

Use Vendor Number as key from input to read in Vendor Table 
If Vendor Number found & TAXAWARE Code is <> Blank 

Retrieve Vendor Information, with TXJCD Code 
Else /*** EEEEERRRRRROOOOOORRRRRR** */ 
end; 

If <L' /**** Location For Loaner ****/ 
Do; 

Use Loaner Number as key from input to read in Loaner Table 
If Loaner Number found & TXJCD Code is o Blank 

Retrieve Loaner Information, with TXJCD Code 
Else /*** EEEEERRRRRROOOOOORRRRRR***/ 
end; 

If , c , /* * * * Location For cus tomer #****/ 
Do; 

T_)0* /***** 

Read ZACTLAREA by Landl to retrieve Country Code(i.e. 897 for US) 
if found 

Do; 

Use Country code + Input Customer Number & TXJCD o Blank 
to read in ZKNAl(by KATR6 + ZZKV-CUSNO) 

If Customer Number found & TXJCD o blank 

Do; 

Read Customer Number in ZADRC where ZKN A 1 - ADRNR = 
ZADRC-ADDRNUMBER and ZADRC-NATION = ' ' 
If Customer found & ((ZADRC -ROOMNUMBER and ZADRC-BUILDING) o Blank) 
Do; /* Internal */ 

Retrieve Work Loc, Building 
Go to ZARESO to retrive TXJCD 
Set Location type = T 

End; 

else 

Do; 

Do; /* External */ 
Retrieve KN A 1 -TXJCD 
Set Location type = 'C 
End; /* external */ 
End; /* If work Loc + Bldg was blank on MPP */ 
End; /* if customer found in MPP */ 
Else/* Customer Not found */ 
if Customer is not Found 
Do; 

Use Customer Number to read in ZACUST 
If Customer Number Found & Work Loc + Bldg o Blank 
Do; 

Use Work Loc + Bldg to read in ZARESO 
If Work Loc + Bldg found in ZARESO 
Do; 
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Retrieve TXJCD 
Set Location type = T 

End; 

Else/**** ERROR ***/ 
End; 

Else 

eeeeeerrrrrrooooorrrrrI 



END; /* end of customer not found or TXJCD code is blank */ 

End;/* ZACTLAREA - Country Code found */ 
Else 

/**** EERRRROOORRR Country Code Not found ****/ 
end;/* End of Location type = C */ 

If <!> /**** Work Loc + Bldg Lookup Lo g ic */ 
Do; 

Use Work Loc. + Bldg. # as key from input to read in Building (RESO) table 
If Work Loc. + Bldg. found & TXJCD Code is o Blank 

Retrieve Building Information with TXJCD Code 
Else/* * * EE EEERRRRRROOOOOORRRRRR* * */ 
end; 

End; 

Else 



DP Equipment 



Ilf ASSET_CLASS = <41' 

Do; /***** For DP Equipment****/ 

If customer number NE BLANK 
Do 

Read ZACTLAREA by Landl to retrieve Country Code(i.e. 897 for US) 
if found 

Do; 

Use Country code + Input Customer Number & TXJCD o Blank 
to read in ZKNA 1 (by KATR6 + ZZKV-CUSNO) 

If Customer Number found & TXJCD <> blank 

Do; 

Read Customer Number in ZADRC where ZKNA I -ADRNR = 
ZADRC-ADDRNUMBER and ZADRC-NATION = ' " 
If Customer found & ((ZADRC-ROOMNUMBER and ZADRC-BUILDING) o Blank) 
Do; /* Internal */ 

Retrieve Work Loc, Building 
Go to ZARESO to retrive TXJCD 
Set Location type = T 

End; 

else 

Do; 

Do; /* External */ 
Retrieve KNA1 -TXJCD 
Set Location type = 'C 
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End; /* external */ 
End; /* If work Loc + BIdg was blank on MPP */ 
End; /* if customer found in MPP */ 
Else/* Customer Not found */ 
if Customer is not Found 
Do; 

Use Customer Number to read in ZACUST 
If Customer Number Found & Work Loc + BIdg o Blank 
Do; 

Use Work Loc + BIdg to read in ZARESO 
If Work Loc + BIdg found in ZARESO 
Do; 

Retrieve TXJCD 
Set Location type = T 

End; 

Else/**** ERROR.***/ 

End;- 

Else 



Process logic below from "By Employee Serial #"! 



END; /* end of customer not found or TXJCD code is blank */ 
End;/* ZACTLAREA - Country Code found */ 
Else 

/**** EE RRRROO O RRR Country Code Not found ****/ 

END/* Customer NE Blank */ 
Else 

If employeeserial NE BLANK 
Do; 



Process logic below from "By Employee Serial #" 



End; 
Else 

If cost center NE BLANK 
Do; 



Process logic below from "Cost Center(Dept)"| 



End; 

Else /**** EEERRROOOORRRR ****/ 
END; 
Else 



Vendor Number 



If Vendor number o = 1 ' 
Do; 

-Use Vendor Number as key from input to read in Vendor Table 
If Vendor Number Found & TXJCD Code is o Blank 
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-Retrieve Vendor Information with TXJCD Code 
-Set Location jype = 'V /* Vendor */ 
Else 



Process logic below from "By Employee Serial #" 



END; 



|Loaner Number) 



If Loanernumber o = ' 1 
Do; 

-Use Loaner Number as key from input to read in Loaner Table 
If Loaner Number Found & TXJCD Code is o Blank 

-Retrieve Loaner Information, with TXJCD Code 

-Set Locationjype = C L' /* Loaner */ 
Else 



Process logic below from "By Employee Serial #" 



END; 
Else 



Work Location & Building 



If Work loc. + Bldg. num. <>= 6 6 
Do; 

-Use Work Loc. + Bldg. # as key from input to read in Building (RESO) table 
If Work Loc. + Building Found & TXJCD Code is o Blank 

-Retrieve TXJCD Code from RESO 

-Set Location_type = T /* IBM Bldg. */ 
Else 



Process logic below from "By Employee Serial #" 



END: 
Else 



By Employee Serial Number! 
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If EMPLOYEE SERIAL NE BLANK 
Do; 

If employeeserial found 
Do; 

Use Emp. Serial Number as Key to read in Blue Pages 

Use Work Loc + Building # from Blue Pages to read in RESO Table 

IF Work. Loc + Bldg Found 

Retrieve TXJCD Code from RESO Table 

Assign TXJCD 

Set Location_type = T /* IBM Bldg. and work loc. and building */ 
Else /** EEE EERRRR ROOOOR RRR **/ 
End; 

Else 

If employeeserial Not Found 
Do; 

If cost center NE BLANK 
Do; 

-Use cost center as key to read in Bluepages— > Mgr.'s. Serial 
If Mgr.'s Serial Found then 
Do; 

Use Work Loc + Building # from Bluepages to read in RESO Table 
Retrieve TXJCD Code from RESO Table 
Set Location Jype = T /* IBM Bldg. Work Loc. */ 
End; 
Else 

If Mgr.'s Serial Not Found then 
Do; 

-Use Cost Center as key to read in CSKS for Serial 
If Serial Found 

-Use Serial # as Key to read in Blue Pages for Work Loc. + Bldg. 
-If Work Loc. + Bldg. found in Blue Pages 

Use Work Loc. + Bldg. as key to read in RESO Table 
If Work Loc. + Bldg. Found & TXJCD Code o blank 
Retrieve TXJCD Code 

Set Location Type = I' /* IBM Bldg. work Loc. */ 
Else 



Use Country Code to find Default Owner(Serial #)~>Blue Pages — > Work. Loc+Bldg — >RESO- >TXJCD 
If Not Found/*** ERROR**/ ~ I 



Else 



Use Country Code to find Default Owner(Serial #)--> j 
Blue Pages — > Work. Loc+Bldg — >RESO~>TXJCD 
If Not Found /*** ERROR**/ 



If Serial Not Found 



-Use Country Code to find Default Owner(Serial #)-->! 
Blue Pages — > Work. Loc+Bldg — >RESO~>TXJCD 
If Not Found /*** ERROR**/ 
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End; /* Mgr.'s Serial Not Found */ 
End;/ * cost center NE Blank */ 
Else 



Process logic below from "By Customer Number M (When Cost Center is Blank ) 



End; /* end of Employee serial not found */ 

End; /* end of Employee Serial # not Blank */ 

Else 



By Customer Number 



Ilf CustomerNUMBER NE BLANK 
Do 

Read ZACTLAREA by Landl to retrieve Country Code(i.e. 897 for US) 
if found 

Do; 

Use Country code + Input Customer Number & TXJCD o Blank 
to read in ZKNAl(by KATR6 + ZZKV-CUSNO) 

If Customer Number found & TXJCD <> blank 

Do; 

Read Customer Number in ZADRC where ZKN A 1 - ADRNR = 
ZADRC-ADDRNUMBER and ZADRC-NATION = 1 ' 
If Customer found & ((ZADRC-ROOMNUMBER and ZADRC-BUILDING) o Blank) 
Do; /* Internal */ 

Retrieve Work Loc, Building 
Go to ZARESO to retrive TXJCD 
Set Location type = T 

End; 
else 
Do; 

Do; /* External */ 
Retrieve KNA1 -TXJCD 
Set Location type - 'C 
End; /* external */ 
End; /* If work Loc + Bldg was blank on MPP */ 
End; /* if customer found in MPP */ 
Else/* Customer Not found */ 
if Customer is not Found 
Do; 

Use Customer Number to read in ZACUST 
If Customer Number Found & Work Loc + Bldg o Blank 
Do; 

Use Work Loc + Bldg to read in ZARESO 
If Work Loc + Bldg found in ZARESO 
Do; 

Retrieve TXJCD 
Set Location type = T 



-15- 



End; 

Else /**** ERROR***/ 

End; 

Else 



Use Country Code to find Default Owner(Serial #)--> 
Blue Pages — > Work. Loc+Bldg — >RESO~->TXJCD 
If Not Found /*** ERROR**/ 



END; /* end of customer not found or TXJCD code is blank */ 

End;/* ZACTLAREA - Counlxy Code found */ 
Else 

/* * * * EERRRROOORRR Country Code Not found * * * */ 

End; 

Else 



By Cost Center (Dept 



If cost center NE BLANK 
Do; 

-Use cost center as key to read in Bluepages table & Retrieve Mgr.'s. Serial # for cost center . 
If Mgr.'s Serial Found then 
Do; 

Use Work Loc + Building # from Bluepages to read in RESO Table 
IF Work. Loc + Bldg Found 

Retrieve TXJCD Code from RESO Table 

Assign TXJCD 

Set Locationjype = T /* IBM Bldg. and work loc. and building */ 
Else /** EE EE E RRR RRO 00 O R R.R.R **/ 

End; 
Else 

If Mgr.'s Serial Not Found then 
Do; 

-Use Cost Center as key to read in CSKS for Serial 
If Serial Found 

-Use Serial # as Key to read in Blue Pages for Work Loc. + Bldg. 
-If Work Loc. + Bldg. found in Blue Pages 

Use Work Loc. + Bldg. as key to read in RESO Table 
If Work Loc. + Bldg. Found 
Retrieve TXJCD Code 

Set Location Type = I' /* IBM Bldg. work Loc */ 
Else 



/*** EEEERRRRROOOOORRRRRR***/! 



Else; 

If Serial Not Found 

-Use Country Code to find Default Owner in Default Owner table 
If Default Owner (Serial #) found 
Do; 

-Retrieve Default Serial # and Read in Blue Pages 

If Default Serial # Found & Work Loc. + Bldg. o Blank 
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Use Work Loc. + Bldg. as key to read in RESO Table 
If Work Loc. + Bldg. found & TXJCD Code o blank 
Do; 

Retrieve TXJCD Code 

Set Location Type = I' /* IBM Bldg. work Loc. */ 
End; /* end of Work Loc. + Bldg. found & TXJCD Code o Blank */ 

Else /**E£EEEERJlRRRRROOOOOOORRRRRRR *** */ 
End; /* end of Serial # found in Blue Pages & Work Loc. + Bldg. o Blank */ 
Else/* **** EEEEEERRRRRROOOOOOORRRRRRR ***/ 
End; /* end of Default Owner (Serial #) found in Default Owner Table */ 
Else /*•*** EEEEEERRRRRRROOOOOORRRRRRR **•**/ 
End; /* Mgr.'s Serial Not Found */ 
End;/ * cost center NE Blank */ 

Else 



DO; /***+* if Not] of Above condition *****/ 

I*** EEEEERRRRROOOORRRRR *****/ 

End; 



-Kedac-hJ 



Location Type is needed for input type: WEB front-end 



Loc. type Ind. 


Location Type 


V 


Vendor 


c 


Customer 


L 


Loaner 


I 


Building (IBM 



Fields needed from Z tables for Location Derivation Process are included in the attached document along 
with other new/changed Z tables fields: 

Link 



Alfred Byc/s nski on 
Ivan 1 iouftmuL't:; on 
Sms Brown on 
Trauey Sutuulli 01 
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Dave Coitum on 
Nicholas QuuUi'ouchi 
Vincent l-ormule on 
Sharon Perun utiM 
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Future reviewers 


Frya Barnes ; 




Derek Rutledge 
Thomas Feil 
Vincent Forma le 
Margarete Graessle 
Annerose Rieth 
Tracey Santulli 
Robert Setzer 
Ann Mitchell 
Sharon Perun 
Dean Stock well 




Ruecliger Kirschl 




None 



Status In Review 



CR520 Link To synchronize field descriptions in ECF 
See Vinny's document Linlc for field descriptions 



Release 2.2 Notes: 

There are no changes associated with ECF for the Retirement Controller. I added the Retirement Overview- 
details. For some reason, this was not in or it was removed from the original document. (NQI 



New fields have to be created for Capitalizations 
For Transfers new fields have been added . CV< 



OPEN ITEMS: 



The field names shown below for detail page of Capitalizations are the rei 2.1 field names. They should be 
changed to the common descriptions stated in CR520. 



The Error Correction Facility (ECF) is a common set of functions for handling errors generated during the 
processing of inbound bridges. Errors detected by the bridge programs will be routed to ECF for 
correction/resubmission by accounting center users. 

The types of errors that this facility wftuld handle are ones that occur within individual input records. If an entire 
file is in error due to invalid control totalizer other problems with the file the entire job will fail and be handled via 
the job scheduling process, not ECF. 

It is important to understand that the way errors will be handled and reprocessed is dependent upon the point within 
the bridge processing the error originated from. Inbound bridge processing is made up of two distinct phases. The 
first part takes the input data and generates one or more SAP transaction structures from it, fully populated with all 
the data. This first part is called a Process Controller. Validations are performed in the Process Controller as well as 
table lookups which get data not provided in the input record. The second part processes the transaction structures 
into SAP, one at a time. The second part is called the Transaction Controller. 

If an error is detected in the Process Controller, the input structure plus any derived data elements are written to 
ECF. Once the problem is corrected the data is input back into the Process Controller and rerun from the beginning 
of the controller. The transaction structures are rebuilt from the input structure. 

If an error is detected in the Transaction Controller or in one of the transactions it calls, all of the transactions are 
written to ECF. The transaction will have result/error codes with them so that it can be determined which 
transactions successfully processed, which one failed, and which have not run yet. If SAP has been updated by at 
least one of the transactions, error handling is more complex because SAP is left partially updated. The completed 
transactions cannot be rolled back. The Process Controllers cannot handle a rerun of these incomplete records 
unless specific logic is built in for each situation. Rather than incorporate into all the bridges additional logic to 
handle resubmitting the incomplete ECF records, ECF will bypass the Process Controllers and reprocess the errors 
as SAP transactions back into the Transaction Controller. The Transaction Controller will use the result/error codes 
to determine which transactions to process. 

Components 

Insert Errors to the ECF Table 

All controllers will call a function to insert errors to the ECF tables. The function inserts one process controller 
record or one transaction record each time it is called. If there are a set of transactions to be inserted, the insert 
function is called once for each transaction. 

In addition to inserting the record into the ECF tables, the record is inserted into the corresponding audit trail table 
as well. This record is never changed and will remain as an original copy of the record. 

Dialog to View/Change Error Records 

Maintenance dialogs generated by SAP will be used to view/update ECF data. From these dialogs, users can modify 
individual records, select records to view/update, and perform a mass change against selected records. Creating on- 
line or printed reports with the flexibility to select records, fields, sort sequence and report format is also available 
from the maintenance dialogs. * 

Purging records will be enabled by a user changing the status field on the record to a "P". When the next ECF batch 
cycle runs, all "P" records will be deleted from the ECF tables and moved to the audit trail tables. 

Reprocessing of Errors 

Batch programs will extract records from the ECF tables and resubmit the data to the Process Controller or 
Transaction Controller. The batch programs will support selecting all ECF records for reprocessing or just those 
with a status of "corrected." If another error occurs on a record that has been resubmitted, the record in ECF is 
updated with the new error message. If the record is successfully processed the new record is moved to an audit trail 
table and the original record is deleted from the ECF table. 



Archive Process 

An archive process is used to reduce the amount of data being stored in the ECF Audit Trail tables. Records will be 
selected to be archived and be removed from the table and put into files to be stored for historical purposes. It is not 
expected that users will use the archived data in MVS very much. 



Aiidit Trail 

Audit trail tables will contain a copy of the original and corrected records. The audit trail table is populated with 
the original record when the error is first inserted into ECF. After the corrected record has been successfully 
reprocessed into SAP it is deleted out of the ECF table and inserted into the audit trail table. 

Authorization 

Authorization will be set up using standard SAP authorization objects and groups. There is one authorization group 
per table or related groups of tables. From these profiles, on-line ECF processing is able to perform the following 
validations and processing. 

• Determine if a user has no access, read access, or update access to the table they selected. 

• Select and allow access to the data for only the country or countries defined in the authorization project. 

Users will be granted either read or update access to specific ECF tables and countries. Authorizations based on 
specific fields is not provided. If a user has access to a table they can view/change the entire record. Certain fields 
in a record are display only, but they will be display only to all users. 



Assumptions 

SAP authorization objects and profiles will be defined outside the scope of this PFS. 

The structures of the various transactions can be found in the AD Design documents or in SAP. 
ECF Error Tables 

Errors are stored in SAP user defined tables (commonly called Z-tables). All tables are client dependent. Each 
unique data format is stored in a separate table. The tables have two logical parts. One contains the data in common 
across all records. These are key fields, control information, error message, machine type and serial, etc. The other 
part of the table contains the data specific to the particular record format The elements making up the common part 
of the tables are listed here. The table name of each of the individual formats is listed after the common fields. See 
the table layout in the SAP data dictionary for the fields/field sizes of each of the tables via transaction SE1 1 . 

Common Data Fields 



• Client 

• Country 

• Feeder Source Code 

• Bridge Sequence Number 

• Bridge Record Number 



Transaction Sequence Number 
Status 

SAP SubRC 

SAP Message Type 

SAP Message Identification 

SAP Message Number 

SAP Message Text 

SAP Message Variable 1 

SAP Message Variable 2 

SAP Message Variable 3 

SAP Message Variable 4 

Original Run Date 

Original Run Time 

Change Date 

Change Time 

Change Userid 

ECF Completion Date 

Process Type 

SAP Transaction Code 



Process Controller and Transaction Specific Data Formats 

The following table contains a list of the individual data formats supported in ECF. Each of the formats in the table 
below have an associated audit trail table and screens for each table. 



Data Format 


(SAP Table Name,; 


Transaction Description 


Capitalization Controller 


|ZATECFCAPS 


Capitalizations 


Transfer Controller 


|ZATECFTFRS j 


Transfers 


Retirement Controller 


jZATECFRETS j 


Retirements 


Project Controller 


|ZATECFPROJ 


Projects 


ABAV 


(ZATECFABAV 


Retirement 


ABUM 


ZATECFABUM 


Transfer 


ABZK 


ZATECFABZK 


FI Posting 


ABZU 


ZATECFABZU 


Write-up of special depreciation 


AMTS 


ZATECFAMTS 


Amounts for ABZK postings, linked 
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; 
1 




to an ABZK for intercompany 
trans frers 


AS01 j 


ZATECFAS01 


Create Asset Master 


AS02 ! 


ZATECFAS02 


Update Asset Master 


ash ; 


ZATECFAS11 


Create Asset Subnumber 


FB01 


ZATECFFB01 


FI Posting 


FB08 


ZATECFFB08 


FI Reversal 


KOOl 


ZATECFKO01 


Create Internal Order 


KO02 


ZATECFKO02 


Update Internal Order j 


KOH1 


ZATECFKOH1 


Create Order Group 




ZAlbCrKUHz 


Update Order Group 


FM7 1 




Create Funds Reservation 


FMZ2 


ZATECFFMZ2 


Update Funds Reservation 


FMZ4 


ZATECFFMZ4 


Reduce Funds Reservation 


OIPC 


ZATECFOIPC 


Insert PCF Delta Transactions into 
ECF j 


K022 j 


ZATECFK022 


Update Budget j 



Depreciation Areas Table 

In the cases where an AS01 or AS 1 1 transaction is stored in ECF, the depreciation data extracted from the 
ZAASSETCLS table (depreciation area, useful live, period and calculation key) is stored in a separate table. The 
table supports a variable number of rows of depreciation data per AS01/AS1 1 transaction. The keys of the table 
provide linkage to a specific AS01 or AS1 1 transaction. Since it is directly linked to other ECF tables, it does not 
contain many of the common data fields contained in the other tables. A sequence number is used to provide a 
unique key for each row. The table name for this table is ZAECFDEPR. There is no audit trail table or screens to 
access the depreciation area. SE16 or SE17 can be used to view the table when necessary. 

Posting Amounts Table 

In the cases where an ABZK transaction which is part of an intercompany transfer is stored in ECF, as many as 15 
amounts for each depreciation area can be part of the ABZK transaction. These amounts are stored in a separate 
table. The table supports a variable number of rows of amount data per ABZK transaction. The keys of the table 
provide linkage to the specific ABZK transaction. Since it is directly linked to other ECF tables, it does not contain 
many of the common data fields contained in the other tables. A sequence number is used to provide a unique key 
for each row. The table name for this table is ZATECFAMTS. While this table is structured the same way as the 
depreciation areas table, note that it does have an audit trail table. SE16 or SE17 can be used to view the table when 
necessary. 

Audit Trail Tables 

The audit trail tables are identical to the corresponding ECF tables and contain the original and corrected record 
once the record has been successfully processed into SAP. The layout is the same for the audit trail table except the 
status is a part of the key. All SAP tables must have a unique key and that status will make the original and 
corrected records have different keys. The depreciation area table does not have a corresponding audit trail table. 

Error Messages 
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The SAP error message table is used to hold the error messages. Message class ZA has been defined for the Fixed 
Assets user defined messages. This table has multiple language capability. 



The following diagram illustrates the overall flow of the ECF process. Included in the diagram are control points, 
highlighted in red. Following the diagram is a description of the control points. 

Below the diagram and control points are descriptions of each of the ECF functions. The functions are grouped into 
five major parts, the red shaded box representing the function to insert errors, the computer terminal representing the 
dialog screens, the blue shaded boxes representing the reprocessing of errors, and the green shaded box representing 
the archiving of audit trail information. 



Control 
Points 


Specific 
Control 
Point? 


Description 


la 


No 


• Authorizations. 


HCFC2a 


YES 


• Authorization by Country 


ECF4bl 

j 


!l _J 


• An audit table will contain copies of every record (original and final) plus the person who last changed it. j 


ECFSbl 

1 


Yes 

i 


• Bridge program startup: for regular runs do a sequence check and verily that bridge status = 'not run'. j 
For restarts do a sequence check and verify that bridge status = 'run'. j 


ECF3K2 

i 


Yes 


• An ASCA report should provide ASCA totals. ASCA totals must be compared to details created by bridge. After \ 
ASCA program completion (good counts) the sequence number should be updated and the status set to 'not run'. 


ECF3cl 


Yes j 


• Archive process startup: for regular runs verify that bridge status = 'not run'. For restarts verify that bridge status 
= 'run 1 . 


ECF3b3 


Yes 


• An ASCA report should provide totals for the ECF archive process. The report should include counts of the 
records in each of the tables before and after the archive is run tied out against the number of records extracted and 
archived. 


ECF3c3 


Yes 


• A control record is put on the top of the outbound archive file. 



Function BF10 is called by any controller that needs to write records to the ECF error tables. In cases where a 
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controller must write multiple records, it must call this function once for each record to be written to ECF. BF10 
performs one of the following four operations based on parameters passed to it 

• Creates a new record in ECF and the ECF audit tables. This is for the case when an error is first produced 
by the bridges. 

• • Update the record in the ECF table. This is for the case when an ECF reprocess of an error fails again. 
The error message and the derived fields are updated with the new values generated by the rerun. 

• Delete the record in the ECF table and insert it into the ECF audit table. This is for the case when a record 
has been successfully reprocessed and it needs to be moved to the audit trail table. 

• Delete both the ECF and audit trail record. This is for the case when a rerun of a process controller record 
makes it through the process controller, but one of the resulting SAP transactions fails. The process 
controller record is deleted from both tables and the transaction error records are inserted in its place. 



Edits/Enrichments 

The status field must contain a value in the following list 
'ECNSKRAF 

The status field on successfully processed transactions has to be mapped to a new value based on it's original value 



Status in ECF prior to ECF run 


New Status in ECF or ECF Audit 


C - Changed by a user 


K - Changed by a user and successfully rerun j 


E - Not changed by a user 


R - Not changed by a user and successfully rerun! 


N - Not yet run 


S - Successfully processed on the first try 



Note that successfully processed records could remain in the ECF tables in the case of transaction records. This 
happens when a transaction is successfully processed, but a subsequent transaction in the set fails. 

Dependencies 

Stable field lists for all controllers and transactions. 
Output 

ECF and ECF audit trail tables 
Exceptions, Errors & Handling 

If a failure occurs in writing to the ECF error tables the bridge program should abend. The error message should 
indicate what table and what the key of the record was at the time of the failure. ECF must be capable of restarting 
at the point of failure once the problem is corrected. 



A set of dialog screens are used to view and modify ECF records. An ECF Table Selection Screen, linked to user 
defined transaction code ZAEC, displays a list of all ECF tables. Selecting a table on this screen transfers control to 
view/update screens for that table. All view/update screens are generated by the SAP View Maintenance Generation 
Tool. The basic functions provided by the SAP generated screens are: 
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• Ability to view/update selected fields for a set of records on one screen, called an Overview Screen. 

• Ability to view/update all fields for one record on a single screen, called a Detail Screen. 

• Ability to select records based on the contents of any or all fields, 

• Ability to purge all selected records. 

• Ability to perform a mass change on a field in all selected records. 

• Ability to dynamically create an on-line report containing any or all fields in all selected records. 

• Ability to print the report or download it to a file. 

ECF Table Selection Screen 

The ECF Table Selection screen contains a list of all ECF tables. Each table is associated with a radio button. Users 
will select one of the tables by depressing the radio button that corresponds to the table, then pressing one of the 
push-buttons. The following is a list of the push-button and their functions. 

• View - displays the entire contents of the selected table in view only mode. 

• Edit - displays the entire contents of the selected table in edit mode. 

• Selection for View - displays selected rows of the selected table in view only mode. Prior to displaying the 
contents of the table, the user can enter selection criteria in a pop-up window, 

• Selection for Edit - same as Selection for View, but in edit mode. 

• Cancel - exit the ECF Table Selection Screen. 

If any of the options other than Cancel are pressed, the Overview screen for the selected table is then displayed. 

To provide for access to data based on the country or countries a user supports, authorization objects will be needed 
to specify the country or countries to which the user has access. The table selection screen will access the 
authorization object to determine the allowable countries. Then, prior to calling the view maintenance dialog for the 
selected table, it populates the countries as selection criteria in a table passed to the view maintenance function. 
This table is used to select and present only the countries authorized. 
Overview and Detail Screens 

The SAP View Maintenance Generation Tool can generate two screens for each table. These screens are called 
Overview and Detail Screens. 

The Overview Screen generated by the SAP View Maintenance Generation Tool provides view/update capability of 
all eligible fields from the selected table and rows. The fields are presented horizontally across the screen, one row 
for each error record. This is similar to the way a spreadsheet is displayed. 

The Detail Screens generated by the SAP View Maintenance Generation Tool provides view/update on a single 
record. All fields are displayed on one screen 

Screen Customization 

To provide additional functions to the users, the generated screens/programs are customized in the following 
manner: 

. • All screens (both ECF and audit table screens) will be modified based on the data content required for each 
screen as well as formatting the screen so that all field labels and data elements are aligned into columns. 
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• For the Capitalization, Transfer, Retirement, and WIP tables, a function will be executed to dequeue the 
table prior to screen display. The SAP generated code will enqueue the table whenever a user accesses it in 
write mode. Dequeuing the table will allow multiple users to access the table in write mode. 

Note: if two users are in write mode at the same time and both update the same record, the last one 
to save the data will have their changes saved. 

• Authority checks will be made to ensure the user has access to view or update the ECF table selected. 

• After a user presses "Enter" or executes any function on the screen, all rows will be checked to see if the 
row has been modified. For each modified row a "C" will be put into the ECF status field, the change 
userid field will be updated with the logon userid, and the change date and time fields will be updated with 
the system date and time. Additionally, a check will be made to see if the status field was modified by the 
user. If so, the value they entered on the screen will not be overlaid by the "C". This allows a user to 
change the "C" on a record to "P" or "E" without having it changed to "C". 

• When a user selects "Save", any row they modified since the last time they saved their data will be checked 
against the current contents of the ECF table to see if that row has been deleted from the table by another 
user or by the batch process. If so, that row will be removed from the user's session. This is done because 
the standard SAP screen functions would re-insert the row back into the table in this case. A re-insert of a 
row deleted by the batch process would make the batch process fail the next time it ran. 

The following sections list the fields displayed on the controller ECF screens by type. An * following the field 
indicates that it is non-modifiable. The transactions screens are not listed separately since they contain all fields 
passed to the transaction function module and all fields are modifiable. 

Capitalizations, including Posting to WIP 

• Country* 

• Controlling Area* 

• Feeder Source Code* 

• Bridge Sequence Number* 

• File Record Number* 

• ECF Status 

• Original Date/Time* 

• Change Date/Time* 

• Change Userid* 
' • Message* 

• Cap. Type 

• Machine Type 

• New Mach Type 

• Model 



New Model 



• Asset Serial (with an 'X' in position 1 8) 

• Fiscal Depr. Life Yrs. 

• Fiscal Depr. Life Periods 

• WT Depr. Life Yrs. 

• WT Depr. Life Periods 

• Local Language Desc. 

• English Description 

• I BM Equipment Category Replaced by Usage code 

• New/Used Indicator 

• Domestic/Foreign Indicator (hide) 

• Property Indicator 

• Responsible Cost Center 

• Employee Serial 

• Customer Number 

• Location/Building Replaced by Worklocation / Building (two fields) 

• Vendor 

• AAS Status Code 

• Contract Type 

• Quantity 

• Transaction Type 

• Posting Date 

• Asset Value Date 

• Document Date 

• Ref. Doc. Number 

• AP Reversal Ref* 

• AP IntOrd* 

• Vat percent* 

• Posting Amount* 

• Posting Sign 
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Amount in Alt. Currency *(hide) 

Supplier 

Intransit LC 

Intransit Div 

Intransit G/L Account 

Cost Element 

Project 

Sub-Project 

Capital Investment Order 

Order Number 

Purchase Order Line Item 

IGS PROJECT NUMBER 

Ship to ZIP code 

Loaner Number 

external purchase indicator 

Bypass Caplimit check (zzmincapo) 



Capitalizations Overview Screen 



Country/Controlling Area; 


Country/Controlling Area | 


FSC 


Feeder Source Code 


BRS 


Bridge Sequence Number 


BR Rec. 


Bridge Record Number 


|e; 


ECF Status 


Ref. Doc. # 


Reference Document Number 


Machine Type 


Machine Type 


Asset Serial j 


Asset Serial # \ 


Cap. Inv. Order 


Capital Investment Order 


Project 


Project j 


Sub j 


Sub-Project | 


C 


Cap. Type \ 


R (Rental Indicator) 


change to Usage Code 


Posting Amount 


Posting Amount 


D 


Debit/Credit Sign 



Transaction 


Transaction Type 


JvCiU. V_/UbL center 


rvcbponsiDie l^osl ^enier 


^UbLUIIJCl ft 


L^USIOlTiei if 


C/ijipiuycc oci idi 


employee oeiiai 


Tn+rcincit T (~* 


intrdnsu Lfcagci L^oue 


llltl alii IL LyJ V 


in trans. it uivision 


Tntr5inci1" A rp1' 
UlllalJoll nut/l 


Inti*annt A r> r\i mi- 
Ill II dlibJL ACCOUIJI 


A ppt 1 /Pnct PI 


/iccoum l/uosi iLiemeni ^was L/ine item i ) 


Ui.UCI iNUUJUCI 


(Irn at* * i tvi r\ 

\J1 Qcl iNUlTlDcI 


Asset Value Oate 


Asspt \/?i1iip Datp 


Posting Date 


Posting Date 


Orig. Run Date 


Original Run Date 


Change Date 


Change Date 


Change Userid 


Change User ID 


Message Text 


Message Text 



List field info and/or flow logic for a fn module 
pool's screen(s) ] 



Screen Info for S APLZAES 0011 - Viewpflege; Detailbild ZAVECFCAPS 



Fullscreen 



. . + . .110 .... + . | 












| 001 














j 002 


1 

[ Cntry/Cont Area 






Orig Date/Time 






| 003 


1 1 ~ 
1 Fsc/Bsn/Brn 






Chang eDate /Time 






| 004 


i i 

ECF Status 






Change Userid 






1 005 


1 1 
| Message Text 








1 


1 


| 006 
1 007 














| 












| 008 


| 

| Cap Type 

1 1 






Cap Usage 


Resp. cost cent 




] 009 


Machine Type 


New 


Mach Type 


New/Used Indie 


Employee Serial 




| 010 


i i 

] Model 


New 


Model 


Property indie. 


Customer Number 




I on 


1 1 
i Asset Serial 






ITG Skip Indie. 


IGS-Proj ect 
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012 



013 



014 
015 



016 



FI Life/Yrs/Per 
I 

WT Life/Yrs/Per 



Local Lang Desc 

i i 

English Descr 

i I 

WorkLoc/Buildg 



Ship to zip 



Ext .pur . Indie. _ Vendor Number 
Loaner Number 

AAS Stat . Code 

Contract Type 

Quantity 



017 
018 



019 



020 
021 
022 
023 
024 
025 



026 



027 



028 
029 



030 
031 
| 032 



I 



•Posting Data 

i 

Transact ionType 



Byp . caplim . chk _ 



Posting date 

I 

Asset val. date 

i i 

Document Date 

i i 

Ref Doc Number 

i i 

VAT percentage 

i i 

Posting Amount 

i 

Supplier 



Int LC/Div/Acct 
I 



-Capital Tracking Data- 

| Project 

| Sub-project 

Cap Invest Ord 
j Lineltern 1 Acct 
I Order Number 
1 Ord Nm Line Itm 



-Reference Data 

| Reversal reference 
| AP Order Number 
I 



ZAWECFFB01 : 



field info and/or flow logic for a fn module pool's screen (s) 

1 



List 



Transfers Screen 

• Country Code*/Controlling Area* 

• Feeder Source Code* 

• File Sequence Number* 

• File Record Number* 

• ECF Status 
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• Original Run Date/Time* 

• Change Date/Time 

• Change Userid 

• Serial Number (with an 'X' in position 1 8) 

• Machine Type*( Pos. 1-4 of In ventory Number) 

• Asset Serial ""(positions 5-25 of Inventory Number) 

• Asset Val. Date 

• Posting Date 

• To Cust Number 

• To Asset Class 

• New Inv. Number 

• ToResp Cost Centr 

• Reference Doc 

• Employee Serial 

• Vendor Number 

• Location/Building location and bldg are 2 separate fields and TXJCD field will not be an input only 
derived. 

• Local Lang Desc 

• PCF Usage Code 

• Model 

• Contract Type 

• AAS Stat Code 

• IGS project code 

• To cost center 

• Asset super # 

• Manufacturer 

• OEM Model/serial 

• Comments 

• Contractor serial # 

• Location type 
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• Work location code 

• IBM bldg # 

• Floor/Rm 

• Loaner # 



Transfer Overview Screen 



|Cntry/Con Area 


Country/Controlling Area 


[FSC 


i - 

(Feeder Source Code 


BSN 


Bridge Sequence Number \ 


BRN j 


Bridge Record Number 


bCl^ Status 


ECF Status 


Serial Number 


(Serial Number 


Inventory Number ■ 


Inventory number 


ToRespCostCentr I 


To responsible cost center j 


To Cust Number 


To Customer Number 


To Asser Class 


To asset class 


New Inv Number 


New Inventory number 


[Asset Val. date 


Asset value date 


[Posting date 


Posting date 


[Reference doc. 


Reference document 


Vendor Number 


Vendor Number 


(Employee Serial 


Employee Serial Number 


iLocaticn/Buildg** j 


Location / Building** 






|Local Lang. Desc. 


Local Language Description 


PCF Usage Code** 


PCF usage code** 


Model 


Model \ 


AAS Stat.code 


AAS status code 


Contract type 


Contract type 


Project 


IGS project code 


To Cost center 


To Cost center 


Location Type 


Location type 


Wk Loc code 


Work Location code 


IBM BLDG 


IBM Building Number i 


Loaner Num 


Loaner Number 







.60 + . . .70 +. . .80 + . . .90 + . .100. . 



| 001 I -ECF Control Data- 



| 0 02 || Cntry/Cont Area 

j 003 || Fsc/Bsn/Brn 



Orig Date/Time 
ChangeDa t e /Time 
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I 004 I I ECF Status 



Change Userid 



005 
006 

00 7 


| Message Text 








008 
00 9 
010 
Oil 
012 


Serial number 
| Inventory no. 

Resp CostCenter 
| Profit Center 
| English Descr 


013 




014 




015 


ToRespCostCentr 


Asset val . date 


016 


j To Cust Number 


Posting date 


017 


[ To Asset Class 


To Profit Ctr 


018 | 


New Inv Number 


To Company Code 


020 j 


| To Cost Center 
| To Project 




021 | 






022 | 






023 | 


Reference doc. 


PCF Usage Code 


024 j 


| Vendor Number 


Loaner Nunmber 


025 | 


j Employee Serial 


Model 


026 | 


1 WK Location 


AAS stat code 


027 j 


| IBM BLDG 


Contract type 


028 | 

029 j 
030 


| Location type 
| Local Lang Desc 





Retirements Overview Screen 



Cty 


Country 


CO Area 


Controlling Area 


FSC 


Feeder Source Code 


BR Seq 


Bridge Sequence Number j 


|BR Rec. 


Bridge Record Number 


pECF Status s 


ECF Status ! 


(Serial Number 


Serial Number 


Inventory Number 


Inventory Number 


Transaction Type 


Transaction Type 


Asset Sub No. 


Asset Subn umber 


Ref. Doc. Number 


Reference Document Number; 


Asset Value Date 


Asset Value Date 


Posting Date 


Posting Date 


Revenue Amount ! (Revenue Amount 


Export to Country , (Export to Country 


Message Text 


Message Text 



-16- 



Retirements Screen 

• Country Code* 

• Controlling Area* 

• Feeder Source Code* 

• File Sequence Number* 

• File Record Number* 
, • ECF Status 

• Original Run Date/Time* 

• Change Date/Time 

• Change Userid 

• Machine Type* 

• • Machine Serial*(only positions 5-25) 

• Transaction Type ' 

• Asset Sub-Number 

• Reference Doc Number 

• Asset Value Date 

• Message Text* 

• ECF CompI Date 

• Serial Number (with an 'X' in position 1 8) 

• Selection Indicator* 

• Revenue Amount 

• Export to country 

• Posting Date 



Projects Screen - The same changes apply to the Audit Trail Table 

• Country Code* 

• Controlling Area* 
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• Company Code* 

• Feeder Source Code* 

• File Sequence Number* 

• File Record Number* 

• ECF Status 

• Original Run Date/Time * 

• Change Date/Time* 

• Change Userid 

• Message Text 

• Sub-project description 

• Project description 

• Project 

• Sub-project # 

• Project Type (now updateable - was not previously) 

• Cap Invest Ord 

• Order Type 

• Settlement CE 

• Release Quarter 

• Project Manager 

• Organization 

• Program 

• Responsible Cost Center 

• Estimated Start Date 

• Estimated Complete Date 

• New Sub-project # 

• Settlement CE 

• Cost Element 

• Document Type* 

• Amount 
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• Due On 

• Requisition # 

• Requisition Line item # 

• Document Date 

. • Purchase Order # 

• Purchase Order line item # 

• Target Machine type 

• Complete Funds Reserv 

• Close Order* 

• Re-open Order* 

• Expense % 

• Taxability Ind *(and on transaction KOO 1 and KO02) 

• Tax Rate Code* (and on transactions KOO I and KO02) 

• Orig est cost* 

• • Industry Code (and on transaction KO01 and KO02) 

• Tech/Brand (and on transaction KOO 1 and KO02) 

• Product/Family (and on transaction KO01 and KO02) 

• Tracking info* (and on transaction FMZ1 ) 

• Requester* (and on transaction FMZ1) 

• Released Budget* (and on transaction K022) 

• Order Status 

Current Detail Screen 



j .....+ .. .10 + . .'. 10. ...+ .. .30 + . . .40. . 

. .+. .110 | 




.50. ...+ .. .60. ... + .. .70. . 


. . + . . .80. . 


. . + . 


.90 . . 


. . + . .100. . 




1 

| 002 || entry/ Cont Area 




Orig Date/Time 








1 


1 

| 0 03 || Fsc/Bsn/Brn 




ChangeDate/Time 








1 


1 

| 0 04 || ECF Status 
1 




Change Userid 








1 


[ 005 | Message Text 












>l 
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006 
007 
008 
009 
010 
Oil 
012 
013 
014 
015 
016 
017 
018 
019 
020 
021 
022 
023 
024 
025 
026 
027 
028 
029 
030 
031 
032 
034 
035 
036 
037 
038 
039 
040 
041 



Project Data 

I 

Project 

i 

Project desc 

i 

Project Type 

i 

Project Manager 

i 

Cost center 

i 

RespCCtr 

i 

Organization 

i 

Program 



Sub Project Data 

i 

Sub-project 

I 

Sub proj desc 

i 

Cap Invest Ord 

i 

Order type 

i 

Estim. Start Date 

i 

Estim. Compl . Date 

i 

Release Quarter 

i 

Estim . costs 

i 

Target Machine 

I 

Percent 

i 

Close order? 

i 

Re-open order? 

I 

New Sub-project 



Commitments Data-- 

I 

Document date 

I 

Due on 

I 

Req . Number 

I 

Order Number 

i 

Complete Funds? 

i 

Amount 

I 

Settlement CE 

i 
i 



Req Nm Line Itm 
Ord Nm Line Itm 



Proposed Changes (not yet done) The same changes apply to the Audit Trail Table 
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.... + ...10 + ...10 + ...30 +...40 + ...50 +...60 + ...70 +...80 + ...90 + ..10 0. 

.+. .110 | 



| 001 








1 






| 002 


1 

[ | Cnty/Cont Area 


Orig Date/Time 


1 


| 003 


1 
1 

| | Fsc/Bsn/Brn 


ChangeDate/Time 


l 


| 004 


1 
1 

| | ECF Status 
I 


Change Userid 


1 


| 005 


1 

[ Message Text 




>i 


| 006 
| 007 


i 
1 






1 
1 

I 






| 008 


I 

| j Project 


1 




| 009 


i 

j | Project desc 






| 010 


Project Type 

I 






| Oil 


| | Project Manager 
i 






| 012 


1 

j | Cost center 
l 


i 




| 012 


1 

| j Co Code 
i 


I 




| 013 


! 

| | RespCCtr 
i 


i 




| 014 


1 

Organization 
1 


i 




| 015 

| 016 
| 017 


1 

| [ Program 

i j Industry Code 

| | Tech/Brand 

1 | Product Family 


i 

! 

........... 1 




1 
1 






| 018 


1 

; | Sub-project 
i 


i 




| 019 


i 

| Sub proj desc 
I 


i 




| 020 


1 

I Cap Invest Ord 
i 


i 




| 021 


1 

| Order type 
I 


Order Status | 




022 


1 

| Estim. Start Date 
i 


i 




023 


1 

[ Estim. Compl . Date 


1 


i 

! 


024 

1 


i 

| Release Quarter 






1 

| 025 


1 Estim. costs 
1 


Budget | 




| 026 


| Target Machine 

; i 


Taxability Ind 1 




! 027 


| Percent , 


i 

Tax Rate Code | 




028 


i 

| Close order? 






029 


i 

1 Re-open order? 

i 






030 


i New Sub-project 

i 






031 
032 








i 






033 


i 

[ Document Type 


Tracking info i 
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I 034 | | Document date 

i 

| 03 5 || Due on 

l 

| 03 6 | | Req. Number 

I 

| 037 || Order Number 

i 

| 038 | | Complete Funds? 

i 

| 03 9 || Amount 

| 040 | | Settlement CE 
I 

| 041 | 

I 

Document Type, Order Status , Tracking info, and Requester should not be updateable 



Project Overview Screen 




Country/Controlling Area: 


Countrv/Controllin^ Area 


Company Code 


Company Code 


|fsc 1 


Feeder Source Code 


BRS i 


Bridge Sequence Number 


BRRec. : 


Bridge Record Number 


E 


ECF Status 


Project Type 


Project Type 


Project 


Project 


Sub-project 


Sub-project 


Cap Invest Ord 


Capital Investment Order 


Order Type 


Order Type 


Amount 


Amount 


(Project desc 


Project description 


( Sub proj desc 


Sub-project description 


Cost center 


Cost Center 


Cost element 


Cost element 


Req. Number 


Requisition Number 


Req Nm Line Itm 


Requisition Number Line itenv 


Order Number 


Order Number 


Ord Nm Line Itm 


Order Number Line item 


Estim. Start Date 


Estimated Start Date 


Estim. Compl. Date 


Estimated Completion Date \ 


Release Quarter 


Release Quarter j 


Message Text 


Message Text 



Requester 

Req Nm Line Itm 
Ord Nm Line Itm 
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Screen Info for SAPLZAES 0301 - Viewpflege: Detailbild ZAVECFKO01 
Fullscreen 

Current Layout 

j . ... + .. .10. ... + .. .10. .. . + .. .30 .... + .. .40 .... + .. .50 .... + . . .60. ... + .. .70. ...+ .. .80. ... + . ..90.. .. + ..100.. 



001 
002 


| Cntry/Cont Area 




Orig Date/Time 




003 


Fsc/Bsn/Brn/Tsn 




ChangeDate /Time 




1 

004 


| Status 




Change Userid 




005 

1 


| BusinessProcess 








005 


| Message Text 






>l 1 


007 
008 
009 






| Order 




Company code 




1 

010 


Project 




Resp CostCenter 




1 

011 


| Sub-project 




Cost center 




1 

012 


i Order type 




Profit Center 




.1 

013 


| Est Start Date 




Organization 




1 

014 


j Est Compl Date 




Program 




1 

015 


| Invest Prof ile 




Release Quarter 




I 

016 


Estim. costs 




Project Manager 




1 

017 
1 


| Percent , 




Target Machine 




018 
1 






Transact ionCode 




019 


| Short text 








1 

020 











Screen Info for SAPLZAES 0301 Viewpflege: Detailbild ZAVECFKO01 
Fullscreen 
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Proposed Layout 



. + ...10. ...+ .. .10. ... + .. .30 + .. .40. 



. + . . .50. 



.60. . 



.70. 



.+ . . .80 + . . .90 + . .100. 



| 001 

I 002 

I • I 
| 003 

I I 
| 004 

i 

005 

I 

006 



007 

008 

009 
I 

010 



012 
I 

013 

I i 
014 

I 

015 

i 

016 
1 

017 



-ECF Control Data 

| Cntry/Cont Area 

| Fsc/Bsn/Brn/Tsn 

| Status 

| BusinessProcess 

| Message Text 



Orig Date/Time 
ChangeDate/Time 
Change Userid 



_>l 



| 020 



-Order Master Data 

| Order 

| Project 

| Sub-project 

j Order type 

| Est Start Date 

| Est Compl Date 

| InvestProf ile 

i Estim. costs 

! Expense Part in % 

J | Industry Code 

| | Tech/Brand 

| | Product Family 



! Transact ionCode 
j Short text 



Company code 
Resp CostCenter 
Cost center 
Profit Center 
Organization 
Program 

Release Quarter 
Project Manager 
Target Machine 



Order Status 
Tax Rate Code 
Taxability Ind 



Screen Info for S APLZAES 0311 - Viewpflege: Detailbild ZA VECFKO02 

Fullscreen 

Current Screen - Update Internal Order 



I 



.10 . 



.10 . 



.30. 



.40 . 



.50 . 



.60. 



.70 . 



.80. 



.90. 



.100. 
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001 


















002 

1 

003 


| | Cntry/Cont Area 

| | Fsc/Bsn/Brn/Tsn 




Orig Date/Time 
ChangeDate/Time 




1 

004 

l 

005 


| | Status _ 
BusinessProcess 




Change Userid 




1 

006 


| | Message Text 






>i i 


007 


















008 


















009 


1 [ Order 




Company code 




010 


! Project 




Resp CostCenter 




1 

Oil 


! j Sub-pro j ect 




Cost center 




1 

012 


| | Order type 




Profit Center 




1 

013 


| Est Start Date 




Organization 




. 1 
014 


| Est Compl Date 




Program 




1 

015 


J InvestProf ile 




Release Quarter 




l 

016 


1 | Estim. costs 




Project Manager 




1 

017 

1 

018 
1 

019 


| Percent , 

| Re-open order? _ 
| Close order? _ 




Target Machine 
TransactionCode 




1 

020 


| Short text 








1 

021 











Fullscreen KO02 

Suggested Screen - The same changes apply to the Audit Trail Table 



. .10. . . .+. . .10. 



.80. . 



.+. . .90. 



. + . .100. . 



.30. 



.40. . . .+. . .50. ...+.. .60. 



. + . . . 70 . . . . + . 



001 l-ECF Control Data-- 
0 02 | | Cntry/Cont Area 



003 



004 



Fsc/Bsn/Brn/Tsn 



Status 



005 j j BusinessProcess 

006 | | Message Text 



'I l 



Orig Date/Time 
ChangeDate/Time 
Change Userid 
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_>l I 

i 007 I- 



| 007 










| 008 


| 

| -Order Master Data 








| 009 


| 

| Order 


Company code 


| 010 


i i 
1 1 

i Project 


Resp CostCenter 


| Oil 


1 1 

| | Sub-project 


Cost center 


| 012 


i ] 
1 1 

| | Order type 

i t 


Profit Center 


| 013 


1 1 

| | Est Start Date 

i i 


Organization 


j 014 


I Est Compl Date 

1 1 


Program 


| 015 


j 1 InvestProf ile 

1 | 

1 1 


Release Quarter 


| 016 


Estim. costs 

1 1 


Project Manager 


1 -.017 


Expense part in % , 


Target Machine 


| 018 


II 

! | Re-open order? 


Transact ionCode 


| 019 


II 

i Close order? 

I I 


Taxability Ind 


| 020 

i 


| Order Status 

I I 

| Industry Code 


Tax Rate code 




j 
I 

| Tech/Brand 






i 

| Product Family 




| 021 


l 

Short text 




| 022 


I I 









Screen Info for SAPLZAES 0161 - Viewpflege: Detailbild ZAVECFFMZ1 
Fullscreen 

Current layout of Screen (old CJOl) 
I 

| . . ..+... 10. ...+.. .10. ...+.. .30. ...+.. .40. ...+.. .50. ...+ .. .60. ... + .. .70. ... + .. .80. .., + .. .90.. .. + ..100.. 

I 

I 001 |-ECF Control Data 

I 

| 002 | | country Orig Date/Time 
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003 
I 

004 

005 
I 

006 



007 
008 
009 
010 
Oil 
012 
013 
014 
015 
016 
017 
018 
019 



Fsc/Bsn/Brn/Tsn 

| Status _ 
j BusinessProcess 
| Message Text 



ChangeDate/Time 
Change Userid 



n 



Commitment Data- 
| Project 
| Sub-project 
| Text 

| Document date 
| Company code 
| Order 

| Cost element 
I Amount 



| Due Date 
| Cost center 



Screen Info for SAPLZAES 0161 Viewpflege: Detailbild ZAVECFFMZ1 



Fullscreen 

Proposed layout of Screen 



The same changes apply to the Audit Trail Table 



+. . .10 +. . .10 + . . .30 +. . .40. ...+.. .50. ...+.. .60 + . . .70 +. . .80 + . . .90 + . .100. 



001 



002 

- II 

003 | 

II 

004 | 

II 

005 | 

II 

006 | 



ECF Control Data 

Country/Cont Area 

Fsc/Bsn/Brn/Tsn 

Status _ 

BusinessProcess 

Message Text 



007 
008 

I 

009 

I 

010 



Orig Date/Time 
ChangeDate/Time 
Change Userid 



i 

i 

| -Commitment Data- 

| | Project 

| | Sub-project 



-27- 



03 6 || Req. Number 
037 || Order . Number 

xxx I I Order Type 

Oil j | T ext 



Req Nm Line Itm 
Ord Nm Line Itm 



012 
013 
014 
015 
016 
017 
018 
019 
02 0 
021 
022 



Document Type 
Document date 
Company code 
Order 

Cost element 

Amount 

Due on 

Cost center 

Tracking info 

Requester 



Document Type, Tracking info, order type and Requester should not be updateable 



Screen Info for SAPLZAES 0171 - Viewpflege: Detailbild ZAVECFFMZ2 



Fullscreen 

Current Layout (CJ02) 



.... + .. .10 +. . .10. ... + .. .30. . 



. + . . .40 . 



.50. ...+.. .60. ...+.. .70. ...+.. .80. ...+.. .90 . 



. + . .100 . . 



001 



002 

II 

Q03 

II 
004 

I 

005 

II 
006 



007 
008 

I 

009 

• I 
010 



-ECF Control Data- 
Country 

Fsc/Bsn/Brn/Tsn 
Status 

BusinessProcess 
Message Text 



Orig Date/Time 
ChangeDate/Time 
Change Userid 



-Commitment Data- 

j Project 

| Sub-project 
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Oil | 


Text 


012 | 


Document number 


013 | 


Document item _ 


014 | 


Company code 


015 | 


Overall amount 


016 | 


Complete Funds? _ 


017 | 


Due on 


018 1 - 





Screen Info for SAPLZAES 0171 - Viewpflege: Detailbild 



ZAVECFFMZ2 



Fullscreen 
Proposed Layout 



The same changes apply to the Audit Trail Table 



....+ . ..10. ... + .. .10. ...+ .. .30. ... + .. .40. ... + .. .50. ... + .. .60. + .70. ...+ .. .80. ... + .. .90. 



.100. 



001 



002 

II 
003 

II 
004 

I 

005 

II 
006 



|-ECF Control Data 

i 

! Country/Cont Area 

| | Fsc/Bsn/Brn/Tsn 

| | Status 
i 

| | BusinessProcess 

| j Message Text 



007 
008 

I 

009 

I 

XXX 

010 

I 

012 

I 

013 

I 

036 | 

037 | 
014 

I 

015 

I 

016 

I 

017 

I 

018 



Orig Date/Time 
ChangeDate/Time 
Change Userid 



Commitment Data- 

| j Project 

| Order Type 
Sub-project 



| Document number 
Document Type 

Req, Number 

| 

Order Number 
| Document item 

i Company code 

Overall amount 

| Complete Funds? 

j Due on 



Req Nm Line Itm 
Ord Nm Line Itm 
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I 019 | 

Document Type and order type and amount should not be updateable 

Screen Info for SAPLZAES 0141 -- Viewpflege: Detailbild ZAVECFFMZ6 

Fullscreen (old CJ04) 



+ ...10 + ...10 +...30. ... + .. .40 + ...50. ... + .. .60 + ...70. ...+ .. .80. ... + .. .90 + ..100.. 



001 



-ECF Control Data 

] Country Orig Date/Time 



002 

l" I 

003 | | Psc/Bsn/Brn/Tsn ChangeDate/Time 

ii 

004 | | Status Change Userid 

I i 

005 | | BusinessProcess _ 

ii 

00 6 | [ Message Text 



007 | 

" I 

008 | -Committment Data-- 
-c 

00 9 || Company code 

1 i 

010 | I Document item 

i i 

011 || Document number 

i i 

012 | | Document Date 

I 

013 || Compln ind. 

i i 

014 || Reversal Amount 
I I 

015 || Redn text 



016 |- 
- I 



Screen Info for SAPLZAES 0141 - Viewpflege: Detailbild ZAVECFFMZ6 
Fullscreen 

Proposed Layout l - The same changes apply to the Audit Trail Table 

I 

| ....+ ...10. . + ...10....+ . . .30 .... + .. .40 .... + .. .50 ....+ . . .60... . + ...70. . . . + ...80. . . . + . ..90.... + . .100. 
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001 

002 

I I 
003 

r i 

004 
I 

005 

I I 
006 



-ECF Control Data 

j Country/Cont Area 
| Fsc/Bsn/Brn/Tsn _ 
| Status _ 

| BusinessProcess 

| Message Text 



007 

008 

009 
I 

010 

I I 

037 

on | 
I I 

012 | 

I I 

013 | 

I I 

014 | 

I, I 

015 | 

I I 

016 | 



Orig Date/Time 
ChangeDate/Time 
Change Userid 



-Committment Data 

| Company code 

j Document item 

| | Order Number 

| Document number 

| Document Date 

| Compln ind. 

j ReversalAmount 

| Re dn text 



Ord Nm Line Itm 



I 



Proposed Layout Transaction K022 - The same changes apply to the Audit Trail Table 



+. . .10. . 



, .10 .... + .. .30 .... + .. .40 .... + .. .50. ... + .. .60. 



. .70. 



, .80. ... + .. .90 . 



.+. .100 . 



| 001 

| 002 
11 


1 | "Country/Cont Area ' 




Orig Date/Time 




| 003 


| | Fsc/Bsn/Brn/Tsn 




ChangeDate/Time 




II 
| 004 

1 


| | Status 




Change Userid 




| 005 
II 


| BusinessProcess 








| 006 


| Message Text 






> 1 1 


| 007 
| 008 










| Order 








| 009 


; | Order type 

j Company Code 

j Fiscal Year 









I 

010 || Budget 
I 
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Release Notes 

Release 2.2 

For Project errors from Commitments do a look-up of 'Order Type' before placing the record into ECF table and 
populate the field 'Order type' 

Reporting/Printing 

Both the overview and detail screens provide print capability. Complete flexibility in both record selection criteria 
and fields to print on the report is provided by the SAP screens. No additional function is needed. 

Input 

ECF Tables 

Edits/Enrichments 

No edits will be performed on any data modified by the user. Validations occur when the error is reprocessed. 
Dependencies 

The final list of transactions and fields supported by ECF is determined based on the final content of the controllers 
and transactions supported by inbound bridging. 

Output 

ECF Tables 

Exceptions, Errors & Handling 

Any errors that occur will generate an error message to the screen. 



Scheduled batch programs extract and resubmit the records from the ECF tables. There is one program for each of 
the Process Controller errors and one program for Transaction Controller errors. These programs select records 
based on an input parameter indicating whether to select all records or those with a status of "Corrected". 

Steps Required to Reprocess Error Records 

1 . Extract all records based on input parameter indicating whether to select all records or just changed 
records. 

o When selecting all records, the extract process must NOT select any records with a status of A 
(automatically routed to ECF by the bridge). Any records sent to ECF by a bridge program must 
not be rerun unless a user changes the status. This is done because the controller does not have the 
logic that caused the record to be bypassed and could improperly reprocess the record . 

o When selecting changed records, the extract process must select any records with a status of C 
(changed by a user) or a status of P (user wants the record purged). 

Each of the Process Controller tables/records are processed individually. The Transaction Controller tables 
are processed as a set, with a set of records being related based on country, feeder source code, bridge 
sequence number and bridge record number, thus grouping together a set of transactions which were 
generated by the same input record. When executing a "changed only" run of transaction records the 
extract program must be sure to extract the entire set of transactions, not just the one with the "Corrected" 
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status. A user will only change the transaction that was in error, but the entire set must be extracted and 
sent to the Transaction Controller for reprocessing. 

1 . For all of the records read from the ECF tables accumulate and insert into the ASCA control table the input 
record count, and if the record has a process type of "CAP", accumulate the amount also. Use the sum of 
the posting amounts in all of the records for this amount field. 

2. For each record read from the ECF tables the following processing flow is followed: 

o If the record has a "P" status, call BF10 to move the record from the ECF table to the audit trail 
table. Then insert a record in the ASCA detail table with a result of "P". 

o If the record does not have a "P" status: 

■ Insert a record into the ASCA detail table, leaving the result field blank. Also leave the 
order number and profit center blank so that the ASCA control report will accumulate all 
records into a single entry on the cap control report. 

■ Call the associated Controller to reprocess the record. If reprocessing transactions, first 
insert a set of records with the same record number into the transaction table and call the 
Transaction Controller to reprocess the transactions. The Transaction Controller will 
bypass any transactions that have a system message number which indicates the 
transaction was successfully processed and start processing at the failed transaction. 

■ Update the appropriate ECF tables, and, if necessary, the corresponding ECF Audit tables 
to reflect the reprocessing of the transaction: 

■ If the record or records were successfully processed update the message fields to 
indicate successful completion and move the record from the ECF tables to the 
ECF Audit tables. 

■ If reprocessing a Process Controller record and it failed again in the Process 
Controller, or if reprocessing transactions and one of the transactions failed 
again, then update the message and the derived fields in the ECF tables to reflect 
the new message and status for each transaction. 

■ If reprocessing a Process Controller record and it then fails in the Transaction 
Controller, delete the Process Controller record and insert the transaction 
records in the ECF tables. The record should also be deleted out of the 
appropriate Process Controller Audit Trail table. 

3. Once processing is complete on all selected ECF records, schedule the ASCA control report programs to 
create the control reports from the ASCA tables. 

The following design documents can be referenced to determine how to call the various bridge functions needed by 
the ECF Controller. 

• Capitalization Controller 

• Transfer Controller 

• Retirement Controller 

• Project Controller 

• Transaction Controller 
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Exceptions, Errors and Handling 

• If the ECF table cannot be read, an error should be generated to the SAP job log and the program 
terminated. 

• If any of the ECF or ASCA tables cannot be updated after successful completion of the record into SAP, an 
error should be generated to the SAP job log and the program terminated. All of the tables within the scope 
of a single input transaction should be updated in the same unit of work so that they stay in synch with each 
other. 

• The Controllers could also issue abends which would terminate the job. 

• Similar restart logic used by all bridges and incorporated into the common restart routine should be used for 
restarting jobs which abend. 

Source Structure 

N/A 

ASCA 

Control Reports and Control Points 

Control totals must be produced which include records extracted from ECF, records successfully completed, records 
that ended up back into ECF, and records that were purged from ECF. The corresponding Process Controller 
control report programs should be used to generate these reports. In the case of transaction errors, the control report 
for retirements should be used. 

A program is required that can be run as needed to reduce the amount of data being stored in the ECF Audit Trail 
table. To facilitate the use of this program a date will be set when the record was successfully processed into SAP 
and moved into the audit frail table. Therefore, until the record is corrected, this date will be blank. When running 
the archive process, an archive date parameter will be supplied. This parameter will be used to selectively purge 
from the ECF audit trail tables. All records corrected as of the archive date parameter to be archived. When dealing 
with transaction errors, if a record has been selected for archive all related records (records with a common ECF 
key) are selected as well. 

All records selected to be archived will be removed from the table and inserted into four separate files, one each for 
caps, transfers, retirements and transactions. Records from all of the transaction tables will be merged into the same 
file and sorted so that a set of transactions will appear together in sequence. This file should be automatically sent to 
MVS, where it can be stored for potential use. The files should be generation data sets. Each file must have a 
control header using the SAP development generic format. It is not expected that users will use the archived data in 
MVS very much. It is being stored for historical purposes. 

Archive Control Report 

A control report is required for the Archive Process. The report must provide a totals by capitalizations, transfers, 
retirements and transactions. It should indicate the total number of records present in the ECF Audit Trail Table 
before the Archive Process, the total records archived, and the total records remaining after the archive program 
has been run. For example: 

ECF Audit Trail Table Archive Process 
Date: XX/XX/XXXX 

Records Read 
Capitalization Records xxxxxx 
Transfer Records xxxxxx 
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Retirement Records xxxxxx 
Transaction Records xxxxxx 
Total Records Read xxxxxxx 



Records Archived 
Capitalization Records 
Transfer Records 
Retirement Records 
Transaction Records 

Total Records Archived 



xxxxxx 

xxxxxx 

xxxxxx 
xxxxxx 

xxxxxxx 



Records Remaining in Table 

Capitalization Records xxxxxx 

Transfer Records xxxxxx 

Retirement Records xxxxxx 

Transaction Records xxxxxx 

Total Records Remaining xxxxxxx 
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Required fields are marked with the asterisk ( ) and must be filled in to complete the form . 



sr 



Tax Location Derivation Process 
Summary 



Status 


Under Evaluation 




Processing Location 


RSW 




Functional Area 


Shander: Global Fixed Asset Process Software 




Attorney/Patent 
Professional 


Gregory Doudnikoff/RaleigfVIBM 




TpTTea^ 


Gregory Doudnikoff/Raleigh/iBM 




Submitted Date 


4BBft 01:23:18 PM EDT 




Owning 
Division 


CHQ 




Incentive Program 


Lab 


Technology Code 


PVT Score 


No PVT score has been calculated To calculate a PVT score, press the 'Calculate' button. 





Inventors with a Blue Pages entry 

Inventors: Sim Brown/Raleigh/IBM, Diana G Hill/Raleigh/IBM, Vincent Formale/Southbury/!BM 



lillilllll j gnu linn litis Bill!! 



|> Brown, John S. (Sim) 
ll Hill, Diana 
k^9- E^mai e t (V i nn y^ 



832529 
858633 
400692 



10/79QA 
10/79QA 
10/73BX 



526-8705 
526-8701 
376-3410 



Rossi, Deron J. 
Rossi, Deron J. 
Lu pinacci, Ernest J. 



Inventors without a Blue Pages entry / 1 1 
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DilipVatel V 
SeriaNtfumber : (N/A) 
Citizen : US 
E-Mail 
Business 

Srt Gates Road 
VesV New York 13850 
Business Phone\.(607) 798-6244 



Company : Owns his own consulting business 
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Home Address : 

3801 Gates Road 
Vestal, New York 13850 
(607) 729-5894 (R) 



IDT Selection 

Select Functional Area 



ijlDTTeam; j Attorney/Patent Professional: 

| Gregory Doudnikoff/Raieigh/IBM I Gregory Doudnikoff/Raieigh/IBM 



Response Due to IP&L 
*Main Idea 

1 . Describe your invention, stating the problem solved (if appropriate), and indicating the advantages of 
using the invention. 

As part of Worldwide Fixed Asset System 2.2, a new method of determining an asset's physical location 

for US tax reporting purposes was devised. This methodology relies on a series of user-maintained tables- 

that are referenced by a hierarchical program to derive an asset's physical location at the point of jgr 

capitalization or transfer, . . 

2. How does the invention solve the problem or achieve an advantage, (a description of "the invention", 
including figures inline as appropriate)? 

The tax location derivation program performs a series of audits against the information included on the 

asset's incoming capitalization or transfer record. These audits check for the presence of specific ?€> 

information on the record. If that information is not found, the record is passed on to the next audit in the 

heirarchy until no additional checks can be performed. At that point, the record is sent to the error 

correction facility for manual correction by the operations team. If the audited information is found, that 

information is cross referenced against user maintained source tables to derive the asset's new tax 

location. This process of auditing and cross-referencing prevents erroneous location information from Jj. J 

being added to the asset record. The previous tax location derivation often allowed incorrect location 

information to be posted to the asset record. 

3. If the same advantage or problem has been identified by others (inside/outside IBM), howhave those 
others solved it and does your solution differ and why is it better? 

Prior to the installation of this program, the derivation of an asset's physical tax location was reliant upon - ?0 

manual entries' made by each of IBM's thousands of asset owners, if the asset owners failed to input the 

location information on a timely basis (most often the case), then a monthly back end derivation process 

was used to. assign the asset to a 'default' location. This backend process did not reference the asset 

owner's location at all. Rather, the process relied on the department's or facility's location todetermine the n ^ 

appropriate tax location of the asset. This derivation process was found to be inconsistent with IBM's 

asset ownership policies. 

4. if the invention is implemented in a product or prototype, include technical details, purpose, disclosure 
details to others and the date of that implementation. 

This tax location derivation program was implemented as part of Worldwide Fixed Asset System 2.2 on 



Ho 



*CriticaI Questions (Questions 1-9 must be answered in English) 



{^Question 1 
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| On wfiat date was the invention workable? 'WMti Please format the date as MM/DD/YYYY 
I (Workable means i.e. when you know that your design will solve the problem) 



Yes 



Question 2 

Is there any planned or actual publication or disclosure of your invention to anyone outside ™ No 
IBM? 



If yes, Enter the name of each publication or patent and the date published below. 
Publication/Patent: 
Date Published or Issued: 



Are you aware of any publications, products or patents that relate to this invention? O Yes 

© No 



if yes, Enter the name of each publication or patent and the date published below. 
Publication/Patent: 
Date Published or Issued: 



*Question 3 



O Yes 
© No 

used internally in manufacturing, announced for sale, or included in a proposal? j 



Has the subject matter of the invention or a product incorporating the invention been sold, ® No j 



Is a sale, use in manufacturing, product announcement, or proposal planned? O Yes 

No 



If Yes, identify the product if known and indicate the date or planned date of sale, announcements, or 
proposal and to whom the sale, announcement or proposal has been or will be made. 

Product: 
Version/Release: 
Code Name: 
Date: 
To Whom: 

| If more than one, use cut and paste and append as necessary in the field provided 



|*Question4 jjjj Yes 

I Was the subject matter of your invention or a product incorporating your invention used in " No 
1 public, e.g., outside iBM or in the presence of non-IBMers? 



[If yes, give a date. Please format the date as MM/DD/YYYY 



^Question 5 * Yes 

Have you ever discussed your invention with others not employed at iBM? 



If yes, identify individuals and date discussed. Fill in the text area with the following information, the 
names of the individuals, the employer, date discussed, under CDA, and CDA #. 
The code for the Tax Location Derivation program was written by DHip Patel who was employed as a contractor for IBM until \^ 
fltaq^BBO^! when his contract expired. Mr. Patel's contact information is listed under the 'Inventors Without Bluepages j \ 
Entries' section of this document. He was involved in the development of this product from^gPBVMBtthroug! 



^Question 6 


o 


Yes | 


Was the invention, in any way, started or developed under a government contract or 


© 


No 


project? 


o 


Not sure j 


If Yes, enter the contract number ( 
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O Yes 



Question 7 

Was the invention made in the course of any alliance, joint development or other contract ^ No 
activities? U Not Sure 
If Yes, enter t he following: . ; 



Name of Alliance, Contractor or Joint Developer 



Contract ID number 



Relationship contact name 



Relationship contact E-mail 



Relationship contact phone 



TJ 



Yes 



Question 8 

Have you, or any of the other inventors, submitted this same invention disclosure or similar " No 
invention disclosure previously? * 



If Yes, please provide disclosure number below: 



|j*Question9 ^ Yes 

1 Are you, or any of the other inventors, aware of any related inventions disclosures 9 No 

submitted by anyone in IBM pr eviously ? 



if Yes, please provide the docket or disclosure number or any other identifying information below-: 



j Question 10 

I What type of companies do you expect to compete with inventions of this type? Check all that apply. 

Manufacturers of enterprise servers 
|EE3 Manufacturers of entry servers ^ 
iKI Manufacturers of workstations 
J Manufacturers of PC's 
3 Non-computer manufacturers 
3 Developers of operating systems 
3 Developers of networking software 
Developers of application software 
jjKI Integrated solution providers 
IjKl Service providers 
□ Other (Piease specify below) 



Question 11 

If the invention relates to a product or service that is outside the scope of your business unit, please 
recommend IBM business unit(s), IBM location(s) or individual(s) within IBM that you think would provide 
a good evaluation of your invention: 



Patent Value Tool (Optional - this may be used by the inventor and attorney to assist with the evaiua 

(The Patent Value tool can be used by the inventor(s) to determine the potential licensing value of your 
invention.) 
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No PVT score has been calculated, To calculate a PVT score, press the 'Calculate' button. 



Market 

What is the anticipated annual market size (In dollars) that will be captured by your invention? 



CLAIMS 

Question 1 - How new is the technical field? 

Question 2 - How central is the invention to the product(s) which might be expected to contain the 
invention? 

Question 3 - What is the scope of the claim? 
PORTFOLIO NEED 

What are the portfolio needs in the area of your invention? 
EXPLOITATION & ENFORCEMENT 

Question 1 - How easily can the use of the invention by a competitor be detected? 
Question 2 - How easily can the use of the invention be avoided by a competitor? 

BUSINESS VALUE 

Question 1 - What percentage of the companies producing products in the field of this invention might use 
this invention? 

Question 2 - What is the value of this patent to current or anticipated Alliance Activity between IBM and 
other companies? 

Question 3 - What is the value of this patent to current or anticipated Technology Transfer Activity 
between IBM and other companies? 

Question 4 - Does it result in prestige to IBM? 
Post Disclosure Text & Drawings 

Enter any additional information relating to this disclosure below: 
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